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EXECUTIVE  SUMMARY 


The  National  Airspace  System  (NAS)  is  a  complex,  sophisticated  collection  of  hardware,  software,  and 
trained  personnel.  Over  many  decades,  this  system  has  matured  to  the  point  where  it  can  handle,  safely 
and  reasonably  efficiently,  many  millions  of  flights  on  an  annual  basis.  Nonetheless,  the  FAA  and 
Industry  must  find  ways  to  improve  NAS  safety  and  efficiency  while  meeting  the  constantly  increasing 
demand  for  capacity.  The  Safe  Flight  21  program  (a  Govemment/Industry  partnership  dedicated  to 
developing,  demonstrating,  and  evaluating  various  “applications”  that  could  provide  operational 
enhancements  to  the  NAS)  represents  a  major  component  of  this  effort. 

In  order  to  minimize  the  inherent  tension  between  the  need  to  examine  proposed  NAS  changes  thoroughly 
and  the  need  to  implement  NAS  changes  expeditiously,  the  Safe  Flight  21  program  has  initiated  the 
development  of  application  “Checklists”.  The  purpose  of  each  Checklist  is  to  identify  all  the  “level  2” 
tasks  required  to  develop  and  implement  an  application  in  the  NAS,  and  to: 

•  Plan  and  track  program  activities,  schedules,  and  responsibilities  for  the  application 

•  Address  stakeholder  resource  needs  and  build  agreements  between  stakeholders/activities 

•  Educate  all  involved  parties  and  manage  expectations 

•  Achieve  buy-in  from  stakeholders  and  participants  (FAA,  Industry,  and  other  Federal  agencies) 

This  document  presents  a  generic  Checklist  to  be  used  as  a  program  plan  template  for  developing  various 
Checklists  for  specific  Safe  Flight  21  applications  and  applications  sets.  The  first  several  Checklists  to  be 
developed  are  shown  below. 

Phase  1  Terminal  Domain  Applications  Set  tincludes  the  following  applications:) 

3.1.1,  Enhanced  Visual  Approaches  (existing  procedures  using  ADS-B  only) 

3.1.2,  Enhanced  Visual  Approaches  (new  procedures  using  ADS-B  only) 

3.1.3,  Enhanced  Visual  Approaches  (new  procedures  using  ADS-B  and  TIS-B) 

4.1.1,  Enhance  Visual  Acquisition  See-and-Avoid  (using  ADS-B  only) 

4.1.2,  Enhance  Visual  Acquisition  See-and-Avoid  (using  ADS-B  and  TIS-B) 

Phase  1  Surface  Domain  Applications  Set  (includes  the  following  applications:) 

6.1.1,  Runway  and  Final  Approach  Occupancy  Awareness  (ADS-B  only) 

6.1.2,  Runway  and  Final  Approach  Occupancy  Awareness  (ADS-B  and  TIS-B) 

6.2,  Airport  Surface  Situational  Awareness 

7.1,  Enhance  Existing  Surface  Surveillance  with  ADS-B 
Surface  Management  System  (SMS) 

Phase  1  General  Aviation  Domain  Applications  Set  fincludes  the  following  applications:) 

1.1.1,  Weather  Alerts 

1.1.2,  Weather  Products 

2.1,  Low-cost  Terrain  Situational  Awareness 

This  generic  Checklist  (program  plan  template)  provides  background  and  introductory  material  to  aid  the 
reader  in  understanding  the  origins  and  scope  of  the  Checklist,  and  describes  both  the  components  of  the 
Checklist  and  how  the  application  stakeholders  (FAA,  Industry,  and  other  Federal  agencies)  will  use  it. 
This  document  is  also  intended  to  serve  as  the  basis  upon  which  the  authors  of  this  document  and  the 
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affected  FAA  LOBs  and  other  stakeholders  work  together  to  refine  the  contents  of  specific  Checklists. 
This  will  require  that  the  FAA  LOBs  and  other  stakeholders  review  the  Checklist,  identify  changes 
required,  assist  in  developing  changes  and  improving  articulation  of  issues,  identify  issues  that  should  be 
raised  to  higher  levels  for  resolution,  and  help  the  authors  work  toward  consensus  among  interfacing 
organizations. 

The  contents  of  this  document  were  developed  in  harmony  with  the  Safe  Flight  21  Master  Plan,  Safe 
Flight  21  High-Level  Concepts  of  Operations,  and  the  RTCA  Template  for  ADS-B  Applications  (“13- 
Step  Process”).  Additional  inputs  from  application  stakeholders,  issues  and  resolution  documents,  test 
and  evaluation  plans,  and  the  ADS-B  Research  Evaluation  Plan  (REP)  were  used  to  provide  the  basis  for 
the  detailed  activity  descriptions  contained  in  the  Checklist.  As  the  contents  of  the  Checklist  are  refined 
and  consensus  is  obtained,  the  Master  Plan  and  other  documents  will  be  revised  (as  appropriate)  to  reflect 
the  results  of  this  consensus. 

The  Safe  Flight  21  (SF21)  Program  is  a  Govemment/Industry  partnership  dedicated  to  developing, 
demonstrating,  and  evaluating  various  “applications”  that  address  nine  potential  operational 
enhancements  of  the  NAS.  The  FAA  and  Industry  are  considering  roughly  two  dozen  “applications”  as 
candidates  to  achieve  these  nine  enhancements.  Efforts  are  underway  to  evaluate  these  applications  via 
simulation  and  flight  testing  in  operational  environments.  The  SF21  Program  hopes  to  validate  the 
anticipated  increase  in  safety,  efficiency,  and  capacity  benefits  and  thereby  expedite  these  applications 
and  their  associated  emerging  technologies. 


1.  INTRODUCTION 


The  National  Airspace  System  (NAS)  is  a  complex,  sophisticated  collection  of  hardware,  software,  and 
trained  personnel.  Over  many  decades,  this  system  has  matured  to  the  point  where  it  can  handle,  safely 
and  reasonably  efficiently,  many  millions  of  flights  on  an  annual  basis.  None  the  less,  the  FAA  and 
Industry  must  find  ways  to  improve  NAS  safety  and  efficiency  while  meeting  the  constantly  increasing 
demand  for  capacity.  The  Safe  Flight  21  program  (a  Govemment/Industry  partnership  dedicated  to 
developing,  demonstrating,  and  evaluating  various  “applications”  that  could  provide  operational 
enhancements  to  the  NAS)  represents  a  major  component  of  this  effort. 

Historically,  the  minimum  time  required  to  bring  a  capability  involving  new  ground  systems  from  the 
idea  stage  to  implementation  in  the  NAS  was  12-15  years;  if  avionics  equipage  were  required  to  realize 
this  capability  (such  as  those  of  the  Safe  Flight  21  applications),  the  additional  time  required  to  achieve 
avionics  equipage  in  60  percent  of  the  US  aircraft  fleet  could  be  as  much  as  1 5  -  20  years.  Industry 
expectations  of  Safe  Flight  21,  on  the  other  hand,  were  to  have  over  20  applications  developed,  evaluated, 
and  ready  for  implementation  within  3  years,  with  avionics  equipage  to  occur  soon  after  on  a  very 
compressed  timetable.  As  it  turns  out,  the  Safe  Flight  21  program  has  developed,  evaluated,  and  made 
ready  for  implementation  2  applications  over  the  past  3  years  (Enhanced  Visual  Acquisition  (ADS-B 
Only)  and  Radar-Like  Services  with  ADS-B),  with  possibly  4  more  applications  becoming  ready  for 
implementation  within  the  next  1  -  2  years.  Although  these  accomplishments  imply  that  Safe  Flight  21 
will  achieve  its  objectives  far  more  quickly  than  the  historical  timeframe  of  15  -  35  years,  it  also  implies 
that  Safe  Flight  21  will  not  meet  Industry  expectations. 

Given  these  circumstances,  the  Safe  Flight  21  program,  and  the  FAA  in  general,  face  significant 
challenges,  specifically  in  managing  very  high  (and  in  some  cases  very  low)  expectations  from  certain 
key  sectors  of  Industry,  overcoming  a  perceived  lack  of  FAA  accomplishments  to  date,  working 
efficiently  with  many  stakeholders  (with  many  issues)  while  still  meeting  FAA  obligations,  and  helping 
all  stakeholders  gain  a  sufficient  understanding  of  the  entire  process.  Many  stakeholders  believe  that,  to 
meet  these  challenges,  it  is  necessary  to  develop  a  Checklist  that  clearly  identifies  all  the  tasks  and 
resources  required  to  implement  a  given  application. 

1.1  Purpose  of  the  Checklist 

In  order  to  minimize  the  inherent  tension  between  the  need  to  examine  proposed  NAS  changes  thoroughly 
and  the  need  to  implement  NAS  changes  expeditiously,  the  Safe  Flight  21  program  initiated  the 
development  of  application  “Checklists”.  The  purpose  of  each  Checklist  is  to  identify  all  the 
“level  2”tasks  required  to  develop  and  implement  an  application  in  the  NAS,  and  to; 

•  Plan  and  track  program  activities,  schedules,  and  responsibilities  for  the  application 

•  Address  stakeholder  resource  needs  and  build  agreements  between  stakeholders/activities 

•  Educate  all  involved  parties  and  manage  expectations 

•  Achieve  buy-in  from  stakeholders  and  participants  (FAA,  Industry,  and  other  Federal  agencies) 

1.2  Purpose  of  This  Document 

This  document  presents  a  generic  Checklist  to  be  used  as  a  program  plan  template  for  developing  various 
Checklists  for  specific  Safe  Flight  21  applications  and  applications  sets.  The  first  several  Checklists  to  be 
developed  are  shown  below. 
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Phase  1  Terminal  Domain  Applications  Set  (includes  the  following  applications:) 

3.1.1,  Enhanced  Visual  Approaches  (existing  procedures  using  ADS-B  only) 

3.1.2,  Enhanced  Visual  Approaches  (new  procedures  using  ADS-B  only) 

3.1.3,  Enhanced  Visual  Approaches  (new  procedures  using  ADS-B  and  TIS-B) 

4.1.1,  Enhance  Visual  Acquisition  See-and-Avoid  (using  ADS-B  only) 

4.1.2,  Enhance  Visual  Acquisition  See-and-Avoid  (using  ADS-B  and  TIS-B) 

Phase  1  Surface  Domain  Applications  Set  (includes  the  following  applications:) 

6.1.1,  Runway  and  Final  Approach  Occupancy  Awareness  (ADS-B  only) 

6. 1 .2,  Runway  and  Final  Approach  Occupancy  Awareness  (ADS-B  and  TIS-B) 

6.2,  Airport  Surface  Situational  Awareness 

7.1,  Enhance  Existing  Surface  Surveillance  with  ADS-B 
Surface  Management  System  (SMS) 

Phase  1  General  Aviation  Domain  Applications  Set  (includes  the  following  applications:) 

1.1.1,  Weather  Alerts 

1.1.2,  Weather  Products 

2.1,  Low-cost  Terrain  Situational  Awareness 

This  generic  Checklist  (program  plan  template)  provides  background  and  introductory  material  to  aid  the 
reader  in  understanding  the  origins  and  scope  of  the  Checklist,  and  describes  both  the  components  of  the 
Checklist  and  how  the  application  stakeholders  (FAA,  Industry,  and  other  Federal  agencies)  will  use  it. 
This  document  is  also  intended  to  serve  as  the  basis  upon  which  the  authors  of  this  document  and  the 
affected  FAA  LOBs  and  other  stakeholders  work  together  to  refine  the  contents  of  specific  Checklists. 
This  will  require  that  the  FAA  LOBs  and  other  stakeholders  review  the  Checklist,  identify  changes 
required,  assist  in  developing  changes  and  improving  articulation  of  issues,  identify  issues  that  should  be 
raised  to  higher  levels  for  resolution,  and  help  the  authors  work  toward  consensus  among  interfacing 
organizations. 

1.3  Relationship  to  Other  Documents 

The  contents  of  this  document  were  developed  in  harmony  with  the  Safe  Flight  21  Master  Plan,  Safe 
Flight  21  High-Level  Concepts  of  Operations,  and  the  RTCA  Template  for  ADS-B  Applications  (“13- 
Step  Process”).  Additional  inputs  from  application  stakeholders,  issues  and  resolution  documents,  test 
and  evaluation  plans,  and  the  ADS-B  Research  Evaluation  Plan  (REP)  were  used  to  provide  the  basis  for 
the  detailed  activity  descriptions  contained  in  the  Checklist.  As  the  contents  of  the  Checklist  are  refined 
and  consensus  is  obtained,  the  Master  Plan  and  other  documents  will  be  revised  (as  appropriate)  to  reflect 
the  results  of  this  consensus. 

1.4  Stakeholders  and  participants 

Federal  Aviation  Administration 

Air  Traffic  Planning  and  Procedures  (ATP) 

Aircraft  Certification  Service  (AIR) 

Airway  Facilities  Service  (AAF) 

Communications,  Navigation,  and  Surveillance  Directorate  (ARN) 

Flight  Standards  Service  (AFS) 

FAA  Alaskan  Region  (AAL) 

FAA  Southern  Region  (ASO) 
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FAA  Technical  Center  (FAATC) 

NAS  Transition  and  Integration  (ANS) 

Office  of  Communications,  Navigation,  and  Surveillance  (AND) 

Office  of  NAS  Operations  (AOP) 

Office  of  Systems  Architecture  and  Investment  Analysis  (ASD) 

Office  of  Systems  Safety  (ASY) 

Operational  Support  (AOS) 

Requirements  Development  Directorate  (ARR) 

Seattle  Aircraft  Certification  Office 

FAA  Unions 

National  Association  of  Air  Traffic  Specialists  (NAATS) 

National  Air  Traffic  Controllers  Association  (NATCA) 

Professional  Airway  Systems  Specialists  (PASS) 

Industry  Associations  and  Unions 
Air  Line  Pilots  Association  Inti.  (ALP A) 

Air  transport  Association  (ATA) 

Aircraft  Owners  and  Pilots  Association  (AOPA) 

Cargo  Airlines  Association  (CAA) 

Other  Participants 

Airborne  Express 
Allied  Signal 
BF  Goodrich 

Department  of  Defense  (DOD) 

Federal  Express 
Honeywell 

Johns  Hopkins  Univ.  Applied  Physics  Laboratory  (JHUAPL) 

L3  Communications 

National  Aeronautics  and  Space  Administration  (NASA) 

MIT  Lincoln  Laboratory 
MITRE  Corporation 
Ohio  University 
Rockwell-Collins 
RTCA,  Inc. 

Safe  Flight  21  Steering  Committee 
Sensis 

Trios  Associates,  Inc. 

United  Parcel  Service 

United  Parcel  Service  Aviation  Technologies 

Voipe  National  Transportation  System  Center  (VNTSC) 

2.  BACKGROUND 

The  Safe  Flight  21  (SF2 1 )  Program  is  a  Govemment/Industry  partnership  dedicated  to  developing, 
demonstrating,  and  evaluating  various  “applications”  that  address  nine  potential  operational 
enhancements  of  the  NAS: 

1 .  Weather  and  other  information  to  the  cockpit 

2.  Cost-effective  controlled  flight  into  terrain  (CFIT)  avoidance 
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3.  Improved  terminal  operations  in  low  visibility 

4.  Enhanced  see  and  avoid 

5.  Enhanced  en  route  air-to-air  operations 

6.  Improved  surface  surveillance  and  navigation  for  the  pilot 

7.  Enhanced  surface  surveillance  for  the  controller 

8.  ADS-B  surveillance  for  non-radar  airspace 

9.  ADS-B  surveillance  in  radar  airspace 

The  FAA  and  Industry  are  considering  roughly  two  dozen  “applications”  as  candidates  to  achieve  these 
nine  enhancements.  These  applications  currently  include  (as  of  1/12/01): 

1.1.1  Initial  FIS-B 

1.1.2  Additional  FIS-B 

2.1  Low-Cost  Terrain  Situational  Awareness 

2.2  Increased  Access  to  Terrain-Constrained  Airspace 

3.1.1  Enhanced  Visual  Approaches  (Existing  Procedures,  ADS-B  Only) 

3.1.2  Enhanced  Visual  Approaches  (New  Procedures,  ADS-B  Only) 

3.1.3  Enhanced  Visual  Approaches  (New  Procedures,  ADS-B  &  TIS-B) 

3.2.1  Approach  Spacing  for  Visual  Approaches 

3.2.2  Approach  Spacing  for  Instrument  Approaches 

3.4  Departure  Spacing/Clearance 

4.1.1  Enhanced  Visual  Acquisition  (ADS-B  Only) 

4. 1 .2  Enhanced  Visual  Acquisition  (ADS-B  &  TIS-B) 

4.2.1  Conflict  Detection 

4.2.2  Conflict  Resolution 

5.2.1  Pilot  Situational  Awareness  (Beyond  Visual  Range) 

6.1.1  Runway  and  Final  Approach  Occupancy  Awareness  (ADS-B  Only) 

6. 1 .2  Runway  and  Final  Approach  Occupancy  Awareness  (ADS-B  &  TIS-B) 

6.2  (Pilot)  Airport  Surface  Situational  Awareness 

7. 1  Enhance  Existing  Surface  Surveillance  with  ADS-B 

7.2  Surveillance  Coverage  at  Airports  Without  Existing  Surface  Surveillance 

8.2  Radar-Like  Services  with  ADS-B 

8.3  Tower  Situational  Awareness  Beyond  Visual  Range 

9.1.1  Radar  Augmentation  with  ADS-B  -  Terminal 

9.2.1  Radar  Augmentation  with  ADS-B  -  En  Route 

Efforts  are  underway  to  evaluate  these  applications  via  simulation  and  flight  testing  in  operational 
environments.  The  SF21  Program  hopes  to  validate  the  anticipated  increase  in  safety,  efficiency,  and 
capacity  benefits  and  thereby  expedite  these  applications  and  their  associated  emerging  technologies. 

3.  DETAILED  CONCEPTS  OF  OPERATION  (CONORS) 

RESERVED.  [As  subsequent  Checklists  are  developed,  this  section  will  contain  or  reference  the 
CONOPS  for  the  specific  application(s)  involved.] 

4.  APPROACH 

4.1  Checklist  Concept 

This  document  presents  a  generic  Checklist.  Subsequent  Checklists  will  be  developed  for  specific 
applications  or  applications  sets.  These  subsequent  Checklists  will  be  structured  like  this  document  with 
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introductory  material  (Sections  1  and  2),  detailed  CONOPS  (Section  3),  high-level  descriptions  of 
Checklist  development  phases  and  categories  of  activities  (this  section),  and  detailed  Checklist  activity 
descriptions  (Section  5).  In  total  there  are  approximately  70  activities,  7  management  tasks  and  13  key 
decisions  defined  in  the  current  Checklist.  As  individual  Checklists  are  refined  and  customized  for 
specific  applications  sets,  the  total  number  of  required  items  in  the  Checklist  may  change  accordingly. 

The  basic  structure  of  the  Checklist  is  based  on  RTCA  document  (DO-249)  entitled  “Development  and 
Implementation  Planning  Guide  for  Automatic  Independent  Surveillance  Broadcast  (ADS-B) 
Applications.”  This  document  was  intended  to  identify  the  range  of  activities  that  need  to  take  place  in 
order  to  guide  an  application  from  an  initial  concept  to  operational  use.  This  document  has  come  to  be 
known  as  the  “RTCA  13-Step  Process,”  which  partitions  the  required  activities  into  categories,  or  “steps”: 


Category  Description 

1  Application  Concept 

2  Benefits  and  Constraints 

3  Buy-In/Maturity 

4  Procedures 

5  Human  Factors 

6  Performance  and  Technical  Requirements 

7  Interoperability 

8  Safety 

9  Avionics  and  Ground  Systems 

10  Operational  Evaluation 

1 1  Certification  (Air  and  Ground) 

12  Operational  Approval 

13  Implementation  Transition 

In  the  Checklist,  activities  within  each  category  are  represented  by  a  two-level  numbering  scheme,  where 
the  first  number  represents  the  activity  category,  and  the  second  number  the  specific  activity  within  the 
category  (e.g.,  the  activity  “Analyze  Benefits,”  described  in  detail  in  Section  5,  would  be  identified  as 
Activity  2.3,  since  it  is  the  third  activity  defined  in  the  Checklist  under  category  2).  Products  of  a  specific 
activity  are  represented  by  a  three-level  number,  where  the  first  two  numbers  represent  the  activity  (as 
before)  and  the  third  number  the  specific  product  produced  by  the  activity  (e.g.,  the  product  “Benefits 
Estimates,”  described  in  detail  in  Section  5,  would  be  identified  as  2.3.1,  since  it  is  the  first  product 
defined  in  the  Checklist  under  activity  2.3). 

In  order  to  provide  a  more  comprehensive  view  of  the  development  process.  Program  Management 
activities  (Categoiy  0)  were  added. 


The  activities  in  the  Checklist  are  also  grouped  into  the  following  phases  of  development.  These  phases 
provide  a  method  for  describing  the  flow  of  development  activities  over  time. 

•  Concept 

•  Development 

•  Limited  Evaluation 

•  Full  Evaluation 

•  Post-Evaluation 

•  Investment  Analysis 

•  Step-Up 

•  Implementation 
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•  Transition 

•  In-Service 

The  Checklist  will  be  used  to  plan  and  track  application  development  activities,  address  stakeholder 
resource  needs,  build  agreements  between  stakeholders/activities,  educate  all  involved  parties  and  manage 
expectations,  and  achieve  buy-in  from  stakeholders  and  participants.  The  Safe  Flight  21  Product  Team 
(the  organization  responsible  for  planning,  developing,  and  executing  the  Safe  Flight  21  program)  will  be 
responsible  for  working  with  stakeholder  representatives  in  developing  the  Checklists.  The  Safe  Flight  21 
Strategic  Support  Group  (SSG),  an  FAA  decision-making  body  focused  on  the  strategic  evolution  of  Safe 
Flight  21  goals  and  initiatives  in  support  of  NAS  modernization  (particularly  those  relating  to  ADS-B), 
will  serve  as  the  forum  for  obtaining  consensus  and  buy-in  to  the  Checklists  at  the  management  level. 


4.2  Category  Summaries 

The  FAA  relied  heavily  on  the  “RTCA  13-Step  Process”  in  developing  the  Checklist.  The  structure  of  the 
Checklist  retains  all  of  the  13  steps  (in  the  form  of  activity  “categories”),  and  includes  an  additional 
category  (Category  0)  to  address  the  various  Program  Management  efforts  required  to  support  application 
development. 

The  following  sections  provide  short  descriptions  of  each  Category  of  activities,  the  roles  of  the 
participants  involved,  issues,  risks,  and  interactions  with  other  Categories. 


4.2.1  Category  0:  Program  Management 

Description:  This  category  includes  a  variety  of  management  and  administrative  tasks. 


Activities: 


0. 1  Develop  and  revise  SF21  Master  Plan 

0.2  Develop  and  revise  Checklist 

0.3  Manage  issues  and  risks 

0.4  Administer  SF21  program 

0.5  Coordinate  for  decisions 

0.6  Develop  acquisition  program  plans 

0.7  Prepare  acquisition  contract(s) 


Participants  and  Roles:  The  development  and  revision  of  the  Safe  Flight  21  Master  Plan  is  an 
FAA/Industry  task  done  within  the  purview  of  the  RTCA  Safe  Flight  21  Steering  Group,  with  assistance 
from  MITRE/CAASD.  The  development  and  revision  of  the  Checklist  is  an  FAA  task  involving  the  Safe 
Flight  21  Program  Office,  ASD-140,  and  several  FAA  support  contractors  with  significant  input  from 
FAA  Lines  of  Business  (LOBs)  and  Industry.  Issues/Risk  Management,  Safe  Flight  21  Program 
Administration,  and  Decision  Coordination  are  the  responsibility  of  the  SF21  Program  Office.  The 
development  of  acquisition  program  plans  and  preparation  of  acquisition  contracts  will  be  the 
responsibility  of  a  yet  to  be  selected  IPT. 

Issues  and  Risks:  While  major  program  risks  are  addressed  under  this  category  of  activities,  this 
document  discusses  specific  risks  below  under  the  activity  category  of  concern. 

Interactions  with  Other  Categories:  Efforts  under  this  category  interact  with  the  efforts  of  all  other 
categories  of  activities. 
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4.2.2  Category  1:  Application  Concept 


Description:  This  category  addresses  the  definition  of  operations  and  systems  concepts  both  at  a  high 
level  and  at  the  detailed  level.  High-level  concepts  provide  an  initial  framework  against  which  initial 
studies  are  planned  and  performed.  A  Research  Evaluation  Plan  (REP)  is  also  developed  (collectively  for 
all  applications)  to  help  guide  development  efforts  from  an  Air  Traffic  Control  (ATC)  perspective.  The 
high-level  concepts  and  the  REP  are  developed  in  the  Concept  phase  and  generally  take  several  months  to 
complete.  Detailed  concepts  are  derived  from  the  high-level  concepts  and  from  research  activities 
occurring  in  the  concept  phase.  These  identify  required  development  activities  for  the  application,  the 
systems  and  functionality  required  to  support  the  application,  and  proposed  assignments  of  functionality 
to  systems.  These  detailed  concepts  are  developed  in  the  Development  phase  and  generally  take  several 
months  to  complete.  A  link  assessment  is  also  conducted  at  this  point  (collectively  for  all  applications)  to 
determine  the  most  appropriate  link(s)  for  the  underlying  systems. 

Synergistic  sets  of  applications  are  defined  showing  the  relationships  among  applications  being 
developed,  and  providing  guidance  for  future  evaluations  of  application  sets.  The  detailed  concepts  and 
synergistic  application  sets  are  updated  and  refined  as  the  application  develops.  The  more  significant 
efforts  (about  1-2  months  each)  occur  just  after  limited  evaluations  in  the  Limited  Evaluation  phase  and 
just  after  full  evaluations  in  the  Post-Evaluation  phase. 

At  some  point  in  the  development  cycle,  once  the  issues  raised  in  the  REP  have  been  sufficiently 
addressed,  a  mission  need  is  established  to  define  the  scope  of  the  FAA  program  for  the  ATC/ground 
component  of  the  architecture.  Once  approved,  requirements  documents  are  developed  to  help  baseline 
and  guide  the  subsequent  acquisition. 


Activities: 


1 . 1  Define  high-level  concept 

1 .2  Develop  detailed  OPS  concepts 

1 .3  Develop  detailed  systems  concepts 

1 .4  Identify  synergistic  applications  sets 

1 .5  Perform  link  assessment 

1 .6  Develop  research  evaluation  plan 

1 .7  Establish  mission  need 

1 .8  Develop  requirements  document 


Participants  and  Roles:  The  primary  organization  that  produces  the  operations  concepts  is  the  RTCA  Safe 
Flight  21  Steering  Group  Ops/Procedures  Sub-Group,  which  has  participation  by  FAA  (Air  Traffic,  Flight 
Standards,  SF21)  and  Industry  (CAA,  AOPA,  MITRE).  Various  organizations  produce  specific  systems 
concepts,  but  the  OCG  is  the  organization  that  coordinates  these  various  concepts  with  application 
requirements.  The  OCG  has  both  FAA  (Air  Traffic,  Flight  Standards,  Certification,  Cost/Benefit,  SF21, 
Capstone)  and  Industry  (CAA,  AOPA,  MITRE)  participation.  The  RTCA  Safe  Flight  21  Steering  Group 
approves  the  concepts  for  further  development.  The  FAA  is  performing  the  link  assessment  with 
participation  from  Industry  and  from  Eurocontrol.  The  FAA  develops  the  REP,  mission  need  and 
requirements  documents. 


Issues  and  Risks:  None  of  particular  concern  at  this  time. 

Interactions  with  Other  Categories:  This  category  generally  requires  inputs  either  from  pre-existing 
documents  (such  as  the  roadmap,  MASPS,  etc.  for  initial  concepts),  or  from  development  activities  (such 
as  simulations,  limited  evaluations,  or  full  evaluations)  where  previous  operations  and  systems  concepts 
have  been  evaluated  and  require  modifications.  The  products  of  this  category  generally  serve  as  inputs  to 
all  other  categories  in  the  Checklist,  for  all  phases  of  development. 
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4.2.3  Category  2:  Benefits  and  Constraints 

Description:  This  category  addresses  the  assessment  of  expected  benefits  and  anticipated  costs  associated 
with  the  application,  as  part  of  a  combined  effort  to  address  benefits  and  costs  for  all  applications 
collectively.  These  estimates  are  used  to  assist  stakeholders  in  deciding  whether  development  of  an 
application  should  continue.  Plans  for  operational  analysis,  metrics  definition,  data  collection  and 
analysis  are  developed  in  the  Concept  phase  to  guide  the  assessments  of  benefits  and  costs,  and  generally 
take  several  months  to  complete.  Synergistic  sets  of  applications  are  also  used  to  aid  in  the  assessments. 
Benefits  are  analyzed  for  these  sets  and  for  the  individual  application  based  on  the  application  concepts 
and  the  results  of  development  activities.  Costs  are  estimated  based  on  the  application  concepts  and  the 
synergistic  application  sets.  Benefits  and  cost  estimates  are  used  as  the  baseline  for  Industry  business 
case  development. 

The  cost  and  benefits  estimates  are  updated  and  refined  as  the  application  develops,  with  the  more 
significant  efforts  (about  2-4  months  each)  occurring  just  after  limited  evaluations  in  the  Limited 
Evaluation  phase,  and  Just  after  Full  Evaluation  in  the  Post-Evaluation  phase. 

Industry  business  cases  and  FAA  investment  analysis  are  based,  in  part,  on  the  results  of  the  previous  cost 
and  benefits  analyses,  and  can  dramatically  influence  the  decision  on  implementation. 

Activities:  2.1  Plan  cost/benefit  analyses 

2.2  Analyze  costs 

2.3  Analyze  benefits 

2.4  Develop  Industry  business  cases 

2.5  Conduct  investment  analysis 

Participants  and  Roles:  The  primary  organization  that  produces  the  benefits  and  cost  estimates  is  the 
RTCA  Safe  Flight  21  Steering  Group  Cost/Benefit  Sub-Group,  which  has  participation  by  FAA 
(Cost/Benefit,  System  Architecture,  SF21)  and  Industry  (CAA,  MITRE).  The  RTCA  Safe  Flight  21 
Steering  Group  approves  the  adequacy  of  the  estimates.  In  Industry,  each  business  organization  develops 
its  own  business  cases.  The  FAA  conducts  investment  analysis. 

Issues  and  Risks:  An  effective  estimate  of  benefits  and  costs  for  an  application  (or  set  of  applications) 
requires  the  availability  of  fairly  detailed  operations  and  systems  concepts.  For  many  applications, 
estimates  of  benefits  and  costs  were  developed  without  these  detailed  concepts,  which  may  result  in 
additional  revisions  to  the  estimates  being  required. 

Interactions  with  Other  Categories:  This  category  generally  requires  inputs  from  the  Application  Concepts 
category  to  provide  the  framework  and  guidance  for  the  estimates,  and  from  those  categories  that  provide 
simulation  or  evaluation  results  where  benefits  mechanisms  were  addressed.  The  products  of  this 
category  generally  serve  as  inputs  to  stakeholder  decision-making  processes  (Buy-In/Maturity  category) 
and  to  the  Operational  Evaluation  category  (providing  data  collection  requirements). 

4.2.4  Category  3:  Buy-In  /  Maturity 

Description:  This  category  addresses  the  key  decisions  required  to  develop  and  implement  an  application. 
An  initial  FAA/Industry  decision  resulted  in  the  selection  of  9  potential  NAS  operational  enhancements. 
The  FAA  and  Industry  then  Jointly  selected  and  prioritized  a  set  of  SF2 1  applications  that  could  provide 
these  enhancements.  For  a  given  application  or  set  of  applications,  a  Joint  FAA/Industry  decision  is 
required  to  initiate  a  limited  and/or  a  full  evaluation.  In  parallel  with  these  evaluations,  the  FAA  makes  a 
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decision  on  the  link(s)  that  will  be  used  by  the  systems  supporting  the  application.  After  the  evaluations 
have  been  performed,  the  FAA  decides  whether  all  significant  issues  for  the  application(s)  have  been 
resolved.  If  this  decision  is  positive.  Industry  decides  whether  they  wish  to  pursue  implementation.  The 
decisions  that  are  required  next  are  for  the  FAA  to  make  its  acquisition  decisions,  and  for  the  FAA  and 
the  involved  unions  to  reach  agreement.  Agreement  with  NATCA  is  required  for  changes  that  affect 
controllers.  Agreement  with  PASS  is  required  for  changes  that  affect  maintenance  personnel.  The  final 
decision  is  for  the  FAA  to  decide  to  place  ground  infrastructure  in  service. 

Activities:  3.1  Decision  -  Select  enhancements 

3.2  Decision  -  Select  and  prioritize  applications 

3.3  Decision  -  Go  for  limited  evaluation 

3.4  Decision  -  Select  link(s) 

3.5  Decision  -  Go  for  full  evaluation 

3.6  Decision  -  Mission  need 

3.7  Decision  -  Was  OpEval  adequate? 

3.8  Decision  -  Initial  investment 

3.9  Decision  -  Industry  commits  to  implementation 

3.10  Decision  -  Select  vendor  and  award  contract 

3.1 1  Decision  -  Final  investment 

3.12  Decision  -  Formal  FAA/Union  agreement 

3.13  Decision  -  In-service 

Participants  and  roles:  Either  Industry  or  the  FAA  make  a  few  of  these  major  decisions  individually. 
However,  the  FAA  and  Industry  make  the  majority  of  these  decisions  together. 

Issues  and  risks:  None  of  particular  concern  at  this  time. 

Interactions  with  other  categories:  The  initial  decisions,  selecting  the  9  enhancements  and  selecting  and 
prioritizing  the  SF21  applications  to  be  evaluated,  comprised  the  start  of  the  Safe  Flight  21  program.  The 
link  decision  and  the  joint  FAA/Industry  decisions  required  to  initiate  the  planning  for  a  limited  or  full 
evaluation  requires  inputs  from  most  categories,  but  primarily  from  Benefits  and  Constraints,  Procedures, 
Human  Factors,  Performance  and  Technical  Requirements,  and  Safety.  These  decisions  also  affect 
subsequent  activities  in  all  other  categories,  most  prominently  those  in  the  Operational  Evaluation 
category.  The  FAA  decision,  on  whether  the  evaluations  have  resolved  all  significant  issues  regarding  an 
application(s),  and  the  Industry  decision  to  commit  to  implementation,  require  inputs  from  most  activity 
categories.  These  decisions  also  drive  the  majority  of  the  Certification  and  Operational  Approval 
activities,  following  the  evaluations  that  are  required  to  implement  the  application(s)  in  the  NAS.  The 
decisions  for  the  FAA  to  acquire  ground  infrastructure  rely  primarily  on  activities  in  the  Program 
Management,  Application  Concepts,  and  Benefits  and  Constraints  categories.  The  decision  for  the  FAA 
and  the  involved  unions  to  reach  agreement  requires  inputs  from  and  affects  subsequent  activities  in  the 
Operational  Approval  category.  The  decision  for  the  FAA  to  place  ground  infrastructure  in  service  relies 
primarily  on  the  results  of  activities  in  the  Operational  Approval  category. 

4.2.5  Category  4:  Procedures 

Description:  Based  on  the  operational  concept,  the  current  maturity  of  the  application,  and  with  input 
from  pilots  and  controllers,  a  process  for  developing,  testing,  and  demonstrating  the  procedures  that  are 
necessary  to  support  the  operational  use  of  specific  applications  is  defined.  Simulations  of  procedures 
with  pilots  and  controllers  are  conducted  and  needed  modifications  to  procedures  are  identified.  Training 
materials  are  developed  and  training  of  pilots  and  controllers  who  will  participate  in  the  evaluation  is 
conducted.  These  procedures  are  modified  as  necessary  based  on  simulations  and  flight  evaluations.  (In 


this  category,  proposed  procedures  are  developed  and  tested  in  joint  FAA/Industry  partnership.  Formal 
approval  and  implementation  by  the  FAA  is  part  of  the  Air  Traffic  approval  process  in  Category  12.) 

Activities:  4.1  Plan  procedures  development 

4.2  Specify  procedures 

4.3  Simulate  with  pilots 

4.4  Simulate  with  controllers 

4.5  Train  for  procedures 

Participants  and  roles:  The  Operational  Evaluation  Coordination  Group  (OCG)  is  responsible  for  the 
development  and  evaluation  of  procedures.  OCG  membership  includes  virtually  all  FAA  LOBs,  Industry, 
various  support  contractors,  and  other  Government  agencies. 

Issues  and  risks:  None  of  particular  concern  at  this  time. 

Interactions  with  other  categories:  The  procedures  are  based  on  the  Application  Concept  and  on  the 
results  of  Human  Factors  considerations.  As  they  are  developed  and  evaluated,  procedures  are  a  major 
consideration  in  Safety.  They  also  have  a  significant  interaction  with  Performance  and  Technical 
Requirements.  Results  from  procedure  development  guide  the  creation  and  revision  of  detailed  Ops 
Concepts.  The  proposed  procedures,  training  materials,  and  evaluation  results  are  input  to  the  Air  Traffic 
approval  process. 

4.2.6  Category  5:  Human  Factors 

Description:  This  category  addresses  the  assessment  of  human  factors  issues  and  requirements  related  to 
the  application.  The  FAA  develops  a  human  factors  plan  outlining  the  human  factors  assessment 
activities  to  be  conducted  to  support  the  development  of  the  application.  Initial  cockpit  and  controller 
task  analyses  and  simulations  are  conducted  (about  6  months  to  complete)  in  the  Concept  and 
Development  phases  to  develop  initial  human  factors  requirements  to  guide  subsequent  evaluations  of  the 
application.  These  requirements  are  updated  and  refined  as  the  application  develops,  with  the  more 
significant  efforts  (about  2-4  months  each)  occurring  during  simulations  and  limited  evaluations  in  the 
Limited  Evaluation  phase,  and  during  simulations  and  full  evaluations  in  the  Full  Evaluation  phase. 

Activities:  5.1  Plan  human  factors  activities 

5.2  Analyze  cockpit  tasks 

5.3  Design  cockpit  interface 

5.4  Define  cockpit  interface  standards 

5.5  Analyze  controller  tasks 

5.6  Design  controller  interface 

Participants  and  Roles:  The  OpEval  Coordination  Group  (OCG)  is  the  primary  organization  that  conducts 
and  approves  the  human  factors  analysis  activities.  (The  OCG  has  participation  from  FAA,  Industry,  and 
other  Federal  agencies.)  SAE  is  the  organization  that  defines  and  approves  cockpit  interface  standards. 
The  FAA  is  responsible  for  the  approval  of  controller  interface  standards. 

Issues  and  Risks:  An  effective  assessment  of  human  factors  requirements  for  an  application  (or  set  of 
applications)  requires  the  availability  of  fairly  detailed  operations  and  systems  concepts.  For  many 
applications,  human  factors  requirements  were  developed  without  these  detailed  concepts,  which  may 
result  in  additional  assessments  being  required. 
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Interactions  with  Other  Categories:  This  category  generally  requires  inputs  from  the  Application  Concept 
category  to  provide  the  operational  and  system  conceptual  framework  for  the  human  factors  assessments. 
This  category  also  generally  requires  joint  efforts  with  activities  in  the  Procedures  category,  since  the 
development  of  procedures  and  the  assessment  of  human  factors  by  their  very  nature  are  closely 
intertwined  activities,  and  with  activities  in  the  Operational  Evaluation  category,  since  this  is  where  the 
majority  of  human  factors  operational  data  is  collected.  The  products  of  this  category  generally  serve  as 
inputs  to  both  the  Application  Concept  and  the  Benefits  and  Constraints  categories  (providing  assessment 
results  for  updating  application  concepts  and  benefits  mechanisms),  as  well  as  to  stakeholder  decision¬ 
making  processes  (Buy-In/Maturity  category). 

4.2.7  Category  6:  Performance  and  Technical  Requirements 

Description:  This  category  addresses  the  assessment  of  expected  and  required  system  performance  to 
support  the  application.  An  initial  estimate  of  performance  requirements  is  developed  (about  4  months  to 
complete)  during  the  Concept  phase  based  on  initial  operational  and  systems  concepts  for  the  application, 
and  is  used  as  a  guide  in  the  initial  development  of  the  application.  Estimates  of  expected  performance 
and  required  performance  are  updated  and  refined  as  the  application  develops,  with  the  more  significant 
efforts  (about  2-4  months  each)  occurring  just  after  initial  application  development  in  the  Development 
phase,  just  after  limited  evaluation  activities  in  the  Limited  Evaluation  phase,  and  just  after  full  evaluation 
in  the  Post-Evaluation  phase.  Once  the  estimates  of  required  system  performance  have  been  refined  and 
validated,  performance  standards  are  developed  to  support  the  manufacture  and  certification  of  required 
systems  to  support  the  application.  These  standards  are  developed  in  the  Post-Evaluation  phase,  and  can 
take  up  to  2  years  to  complete.  These  estimates  of  required  system  performance  are  also  used  to  develop 
ground  system  requirements  and  specifications,  which  in  turn  support  subsequent  system  acquisition 
activities. 

Activities:  6. 1  Estimate  performance 

6.2  Define  performance  standards 

6.3  Develop  ground  system  specifications 

Participants  and  Roles:  The  OpEval  Coordination  Group  (OCG)  is  the  primary  organization  that  conducts 
and  approves  the  estimation  of  performance  expectations  and  requirements.  (The  OCG  has  participation 
from  FAA,  Industry,  and  other  Federal  agencies.)  RTCA  SC-186  is  the  primary  organization  that 
conducts  and  approves  the  development  of  performance  standards.  The  FAA  is  responsible  for 
developing  and  approving  ground  system  specifications. 

Issues  and  Risks:  Effective  estimates  of  required  performance  requires  the  availability  of  fairly  detailed 
operations  and  systems  concepts.  For  many  applications,  estimated  performance  requirements  were 
developed  without  these  detailed  concepts,  which  may  result  in  additional  revisions  to  the  estimates  being 
required. 

Interactions  with  Other  Categories:  This  category  generally  requires  inputs  from  the  Application  Concept 
category  to  provide  the  operational  and  system  conceptual  framework  for  the  development  of 
performance  requirements,  as  well  as  inputs  from  the  Interoperability  and  Safety  categories,  which 
provide  additional  potential  requirements.  This  category  also  generally  requires  inputs  from  the 
Operational  Evaluation  category,  which  provides  data  to  validate  the  performance  estimates.  The 
products  of  this  categoiy  generally  serve  as  inputs  to  the  Avionics  and  Ground  Systems,  Operational 
Evaluation,  and  Certification  categories  (providing  guidance  in  the  development  of  avionics,  technical 
parameters  for  simulation  and  evaluation,  and  guidance  for  certification  of  avionics,  respectively). 
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4.2.8  Category  7:  Interoperability 


Description:  This  category  addresses  the  assessment  of  interoperability  requirements  of  proposed  systems 
supporting  the  application.  An  initial  estimate  of  interoperability  requirements  (among  both  airborne  and 
ground  systems,  including  ground-ground  interfaces)  is  established  during  the  Concept  phase  (about 
6  months  to  complete)  based  on  initial  operational  and  systems  concepts  for  the  application,  and  are  used 
as  a  guide  in  the  initial  development  of  the  application.  Validations  of  interoperability  performance  are 
conducted  (about  2  months  each)  based  on  the  outcomes  of  activities  in  the  Limited  Evaluation  and  Full 
Evaluation  phases,  the  results  of  which  are  fed  into  performance  standards  development  activities. 

Activities:  7.1  Analyze  interoperability 

7.2  Define  ground  system  interoperability 

7.3  Validate  interoperability 

Participants  and  Roles:  RTCA  SC- 186  is  the  primary  organization  that  conducts  and  approves  the 
estimation  of  interoperability  requirements.  The  FAA  is  responsible  specifically  for  defining  ground- 
ground  system  interface  requirements.  The  OpEval  Coordination  Group  (OCG)  is  the  primary 
organization  that  conducts  and  approves  the  assessment  of  overall  interoperability  performance.  (The 
OCG  has  participation  from  FAA,  Industry,  and  other  Federal  agencies.) 

Issues  and  Risks:  An  effective  assessment  of  interoperability  performance  requires  the  availability  of 
well-defined  performance  estimates,  which  in  turn  requires  the  availability  of  fairly  detailed  systems 
concepts.  For  many  applications,  interoperability  performance  was  assessed  without  these  performance 
estimates,  which  may  result  in  additional  assessments  being  required. 

Interactions  with  Other  Categories:  This  category  generally  requires  inputs  from  the  Application  Concept 
category  to  provide  the  operational  and  system  conceptual  framework  for  initial  estimates  of 
interoperability  requirements,  and  from  both  the  Performance  and  Technical  Requirements  and 
Operational  Evaluation  categories  to  support  the  assessment  of  interoperability  performance.  The 
products  of  this  category  generally  serve  as  inputs  to  the  Performance  and  Technical  Requirements 
category  to  support  the  development  of  system  performance  standards  and  specifications. 

4.2.9  Category  8:  Safety 

Description:  Safety  activities  guide  the  development  of  applications,  validate  their  safety  to  guide 
decision-making,  and  plan  for  evolution  to  facilitate  subsequent  regulatory  approvals.  In  the  Concept 
phase,  safety  activities  are  structured  to  efficiently  guide  the  definition  of  the  application.  Safety  works 
closely  with  design  to  evaluate  potential  elements  of  systems  and  procedures.  Some  interacting  elements 
will  be  highlighted  if  they  create  hazards  or  make  hazards  more  difficult  to  mitigate;  others  will  be 
highlighted  because  they  provide  an  assumed  mitigation  and  should  be  maintained  as  designs  evolve. 
Immediate  consideration  of  mitigations  in  early-phase  safety  analysis  allows  efforts  to  be  focused  on 
elements  that  are  most  important  in  developing  an  application  that  can  be  safe.  Subsequent  activities  are 
structured  to  validate  application  safety  and  to  guide  decisions  about  implementation  -  possibly  as  a 
collection  of  applications.  In  this  subsequent  process,  mitigations  are  considered  only  after  hazard 
severities,  probabilities,  and  interactions  have  been  evaluated.  The  levels  of  safety  for  current  operations 
and  proposed  new  operations  are  compared.  Standard  FAA  safety  analyses  are  conducted  in  the 
Implementation  phase  from  a  ground  system  perspective,  once  the  system  acquisition  process  is  initiated. 

In  addition  to  application-by-application  activities  for  development  and  decision-making,  an  over-all 
safety  plan  is  used  to  facilitate  regulatory  approval  and  make  it  more  predictable  for  evolutionary 
extensions  of  capability  that  span  multiple  applications.  This  plan  is  developed  from  applications 
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concepts  and  may  be  revised  as  more  is  learned.  It  lays  out  groupings  and  levels  of  capability  that  should 
be  certified  or  approved  together,  and  boundaries  between  levels  of  capability  that  reflect  the  need  for 
different  (or  additional)  safety  analyses  and/or  certification  and/or  approval.  In  addition  to  these 
activities,  test-safety  strategies  and  reviews  are  developed  with  each  iteration  of  flight-testing,  and  safety 
issues  and  resolutions  are  represented  as  part  of  over-all  SF21  program  management. 


An  evolution  safety  plan  across  all  applications  will  require  6  months  from  the  availability  of  high-level 
concepts  for  the  relevant  applications,  with  later  updates  requiring  2  months  per  year.  Coordinated  safety 
analysis  plans  for  individual  applications  will  require  1  month  each,  plus  revisions  later  for  unexpected 
issues  or  results.  Safety  analyses  for  concept/development  will  extend  the  duration  of  these  phases  - 
about  6  months.  Revisions  during  the  limited  evaluation  and  full  evaluation  phases  will  also  extend  about 
6  months,  but  with  reduced  or  intermittent  effort.  Comparative/validation  analyses  occur  near  or  before 
the  start  of  full  evaluation,  and  analysis  of  the  current-operations  baseline  makes  this  a  significant  effort 
over  a  6-month  interval.  Revisions  after  operational  evaluation  require  approximately  1  month.  FAA 
acquisition  safety  analyses  are  conducted  as  part  of  the  system  acquisition  process,  and  will  require 
approximately  6  months  to  complete  (in  parallel  with  other  acquisition  activities). 


Activities: 


8. 1  Plan  coordinated  safety  activities 

8.2  Summarize  operational  services  and  environment 

8.3  Perform  safety  analyses 

8.4  Allocate  safety  objectives  and  requirements 

8.5  Track  safety  issues  during  development 

8.6  Ensure  safety  of  testing 

8.7  Assess  comparative  safety 

8.8  Formalize  scopes  of  operations 

8.9  Plan  safety  for  implementation 

8.10  Analyze  hazards  of  individual  systems 

8. 1 1  Analyze  hazards  over-all 

8.12  Analyze  hazards  of  operations  and  support 

8.13  Assess  health  hazards 


Organizations  and  Roles:  Safety  planning  for  each  application  will  be  performed  by  (or  for)  the  SF21 
program  office.  The  SF21  Steering  Group  will  develop  and  coordinate  the  evolution  plan  (for  multiple 
applications)  as  part  of  the  periodic  revisions  of  the  SF21  Master  Plan.  The  Safety  Sub-Group  of  the 
OCG  is  responsible  for  test  safety  and  safety  analyses  to  guide  development,  with  participation  of 
FAA/ASD,  ASY,  AFS  and  AIR,  and  by  the  RTCA/SC-189  ASA  MASPS  working  group.  The 
FAA/System  Safety  Working  Group  will  perform  comparative/validation  analyses  to  guide 
implementation  decisions.  They  will  also  be  responsible  for  tracking  and  coordinating  safety  issues  and 
resolutions  with  the  SSG,  the  SF21  Steering  Group,  and  RTCA  SC-189.  The  FAA  IPT  assigned  to  the 
system  acquisition  is  responsible  for  ensuring  that  the  acquisition  safety  analyses  are  performed. 

Issues  and  Risks:  These  safety  processes  are  based  on  the  FAA  "Safety  Handbook",  which  references  the 
coordinated  safety  analysis  process  developed  for  data-link  by  ICAO  and  RTCA/SC-1 89  and  published  as 
RTCA  DO-264.  Integration  of  developmental  and  validational  safety  analyses  and  strategic/evolution 
safety  planning  has  never  been  undertaken,  and  process  specifics  and  buy-in  are  needed. 

Interactions  with  Other  Categories:  Safety  takes  primary  inputs  from  Program  Management,  Application 
Concepts,  Procedures,  Human  Factors,  Performance  and  Technical  Requirements,  and  Interoperability.  It 
interacts  with  these  and  with  Operational  Evaluation,  and  provides  output  to  Application  Concepts, 
Performance  and  Technical  Requirements,  Certification,  and  Operational  Approval,  and  to  decisions  and 
commitments  to  proceed  with  each  application  (Buy-In/Maturity  category).  Safety  activities  are  also 
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performed  in  conjunction  with  activities  in  the  Avionics  and  Ground  Systems  category  during  the 
Implementation  phase. 

4.2.10  Category  9:  Avionics  and  Ground  Systems 

Description:  In  order  to  evaluate  the  safety,  service,  and  procedure  improvements  that  Safe  Flight  21 
(SF21)  applications  may  provide,  it  is  necessary  to  demonstrate  and  evaluate  these  applications  and  their 
associated  avionics,  ground  systems,  and  procedures.  In  the  Limited  Evaluation  or  Full  Evaluation 
phases,  this  may  involve  the  use  of  experimental  equipment.  Demonstration  ground  systems  may  be 
operated  in  a  ‘‘shadow”  mode  while  air  traffic  controllers  use  existing  ground  systems  for  the  actual 
control  of  traffic.  Demonstration  avionics  may  be  certified  with  extensive  limitations  (e.g.,  geographic 
limitations,  date  of  use  limitations,  and  aircraft  serial  number  limitations).  If  flown  on  an  aircraft  in 
experimental  status,  avionics  certification  may  not  be  required. 

Industry  or  Government  develops  avionics  for  various  phases  of  the  demonstration  and  evaluation 
process.  Avionics  used  during  a  limited  evaluation  may  be  of  limited  maturity  and  sophistication. 
Avionics  used  in  a  full  operational  evaluation  should  be  of  a  maturity  and  sophistication  that  allows  a 
complete  evaluation  of  all  significant  issues.  In  addition,  the  avionics  cockpit  interfaces  ought  to  conform 
with  that  for  which  applicants  intend  to  apply  for  certification;  in  some  cases  limited  or  full  certification 
may  be  obtained  prior  to  operational  evaluation.  In  the  Step-Up  phase,  the  applicant  develops  avionics 
that  will  be  submitted  for  certification  (if  not  completed  previously). 

The  FAA  is  responsible  for  the  development  of  ground  systems  that  will  be  implemented  in  the  NAS  in 
support  of  the  applications.  This  involves  the  manufacture,  delivery,  and  integration  of  ground  systems 
into  the  NAS  during  the  Implementation  and  Transition  phases. 

Activities:  9.1  Develop  avionics 

9.2  Develop  ground  systems  for  evaluation 

9.3  Manufacturer  ground  systems  for  implementation 

9.4  Deliver  and  integrate  ground  systems 

Participants  and  roles:  Industry  develops  avionics  and  applies  to  the  FAA  for  certification.  AIR  provides 
policy  guidance  on  certification.  The  actual  certification  is  approved  at  the  regional  level.  The  lead 
region  is  dependent  on  the  type  of  aircraft  (The  Northwest  Mountain  Region  is  the  lead  for  air  transport 
aircraft;  the  Central  Region  is  the  lead  for  general  aviation  aircraft;  the  Southwest  Region  is  the  lead  for 
helicopters  and  tilt-rotor  aircraft.)  Prototype  or  experimental  avionics  may  be  developed  and  used  by 
either  Industry  or  Government  researchers  on  experimental  aircraft.  These  may  include  flyable  versions 
of  prototypes  developed  for  simulations. 

Industry  develops  aviation  ground  systems  to  support  the  evaluations.  Generally,  this  development  takes 
place  under  contract  to  the  FAA  since  the  agency  purchases  and  maintains  the  majority  of  the  ground 
systems  that  make  up  the  NAS.  FAA  certification  of  certain  non-federal  ground  systems  is  required. 
However,  this  is  not  expected  to  apply  to  non-federal  SF21  ground  systems. 

Issues  and  risks:  While  a  portion  of  Industry  expresses  great  eagerness  to  make  use  of  SF21  applications, 
discussions  with  the  avionics  manufacturers  indicate  that  they  are  not  yet  convinced  that  there  is  a 
significant  market  for  their  goods  in  the  near  future.  Consequently,  there  are  limitations  on  the  level  of 
resources  the  avionics  manufacturers  are  prepared  to  invest  in  this  effort  at  this  time. 

Interactions  with  other  categories:  The  Applications  Concept  and  Procedures  categories  identify  what  the 
avionics  are  intended  to  support.  The  Human  Factors,  Performance  and  Technical  Requirements,  and 
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Safety  categories  identify  detailed  avionics  design  requirements.  Consideration  of  the  avionics  and 
ground  systems  is  a  key  factor  during  the  planning  for  limited  or  full  evaluation.  Unless  the  avionics  are 
installed  on  an  aircraft  that  will  be  operated  in  experimental  status,  certification  is  required  for  flight 
evaluation.  Operational  approval  to  use  the  avionics  for  specific  procedures  is  required  for  flight 
evaluation.  The  development  of  implementation  ground  system  requires  inputs  primarily  from  Program 
Management,  Performance  and  Technical  Requirements,  and  Safety  categories,  and  delivers  products 
required  for  activities  in  the  Operational  Approval  category. 

4.2.11  Category  10:  Operational  Evaluation 

Description:  In  order  to  fully  evaluate  the  safety,  service,  and  procedure  improvements  that  Safe  Flight  21 
(SF21)  applications  might  provide;  it  will  be  necessary  to  operationally  demonstrate  and  evaluate  these 
applications  along  with  their  associated  avionics,  ground  systems,  and  procedures.  This  category  of 
activities  addresses  the  planning  and  the  execution  of  both  simulation  and  flight  evaluation. 

Activities:  10.1  Plan  joint  evaluations 

10.2  Simulate  mission 

10.3  Conduct  joint  evaluations 

Participants  and  roles:  The  Operational  Evaluation  Coordination  group  (OCG)  is  responsible  for  planning 
and  performing  joint  evaluation  activities.  The  OCG  is  a  large  group  with  membership  from  virtually  all 
FAA  lines  of  business,  from  Industry,  Labor,  other  Government  agencies,  and  research  organizations. 
Prior  to  a  joint  evaluation,  this  group  meets  over  a  period  of  several  months  to  discuss  and  reach  a 
consensus  on  all  aspects  of  the  evaluations. 

Issues  and  risks:  Joint  evaluations  are  generally  large,  expensive  events  requiring  the  commitment  of 
resources  from  many  different  organizations.  Current  practice  has  been  to  set  an  evaluation  time  frame 
and  then  plan  for  it.  There  is  a  risk  that  all  activities  required  to  support  an  evaluation  may  not 
necessarily  be  accomplished  by  this  time  frame.  If  this  occurs,  the  FAA  and  Industry  must  decide 
whether  to  delay  the  evaluation  in  order  to  make  it  more  productive  or  to  conduct  it  as  scheduled  with  less 
than  maximum  benefit.  Since  this  is  often  a  very  political  decision,  either  the  FAA  or  Industry  may  be 
unwilling  to  delay  the  planned  event.  When  this  occurs,  the  evaluation  then  becomes  more  of  a  publicity 
event  and  less  of  an  event  to  address  unresolved  issues  regarding  specific  applications. 

Interactions  with  other  categories:  The  Procedures  category  identifies  what  the  evaluation  is  intended  to 
support.  The  Human  Factors,  Performance  and  Technical  Requirements,  and  Safety  categories  identify 
detailed  design  and  testing  requirements.  The  Avionics  and  Ground  Systems  category  provides  the 
equipment  that  will  be  used  in  the  evaluation.  Operational  approval  to  use  the  ground  systems  and 
avionics  for  specific  procedures  is  required  for  the  evaluation.  The  results  of  the  evaluation  influence 
subsequent  activities  in  all  categories. 

4.2.12  Category  11:  Equipment  Certification  (Air  &  Ground) 

Description:  An  aircraft,  and  equipment  permanently  installed  in  aircraft,  must  be  certified  for  safety, 
reliability  and  airworthiness  before  it  can  be  flown.  This  category  deals  with  the  process  of  obtaining 
FAA  approval  of  equipment,  particularly  avionics,  for  installation  and  use  in  aircraft.  It  describes  the 
process  and  the  activities  from  initiation  through  final  approval. 

Two  kinds  of  approvals  are  considered  here:  Technical  Standard  Orders  (TSOs)  and  Type  Certificates 
(TCs)  or  more  specifically.  Supplemental  Type  Certificates  (STCs).  A  TSO  is  a  broad  approval, 
providing  a  minimum  performance  standard  for  parts,  materials  or  manufacturing/assembly  processes  and 
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is  not  related  to  a  specific  aircraft  or  aircraft  class,  make  or  model.  Installation  of  TSO  items  in  specific 
aircraft  requires  separate  approval.  The  installation  may  constitute  an  aircraft  design  change  and 
therefore  would  require  an  engineering  design  approval.  The  approval  would  be  in  the  form  of  a  TC  if  it 
were  a  major  change.  When  the  change  is  not  so  extensive  as  to  require  a  new  TC,  an  STC  can  be  used. 

A  third  form  of  installation  approval  is  a  field  approval,  using  FAA  Form  337. 

The  certification  process  can  begin  as  early  as  the  Development  phase,  where  the  manufacturer  initiates 
discussions  with  the  FAA  to  describe  the  new  equipment  and  define  the  scope  of  certification.  Radio 
spectrum  may  be  of  concern  where  a  frequency  or  frequencies  would  be  necessary  for  the  equipment  to 
perform  its  mission.  A  formal  request  for  specific  frequencies  may  be  necessary  and  should  be  initiated 
as  soon  as  possible. 

When  the  equipment  design  has  reached  at  least  an  initial  level  of  maturity,  a  formal  application  should  be 
made  to  the  FAA  for  certification.  The  request  would  contain  a  certification  plan,  at  least  an  initial 
design,  the  regulatory  basis  for  the  certification  and  method  of  compliance.  The  certification  basis  can  be 
federal  regulations  or  other  guidance,  such  as  airworthiness  standards.  Once  the  FAA  has  reviewed  the 
certification  plan  and  concurs,  all  supporting  data  is  submitted,  such  as  a  final  design,  test  plans  and  test 
data.  The  submission  may  contain  an  aircraft  flight  manual  supplement  and,  if  necessary,  a  flight  test 
plan.  Unless  the  aircraft  is  classified  as  experimental,  some  form  of  approval  is  required  before  flight. 
Early  flight  tests  or  demonstrations  may  be  restricted  in  duration,  geographic  area  or  limited  to  a 
particular  aircraft.  The  FAA  may  or  may  not  participate  in  or  observe  the  testing,  depending  on  the 
significance  of  the  certification.  The  final  step  is  the  issuance  of  the  STC  or  TSO,  with  the  objective  to 
receive  certification  on  as  broad  a  basis  as  possible. 


Activities: 


11.1  Obtain  spectrum 

1 1 .2  Plan  and  apply  for  avionics  certification 

1 1 .3  Establish  avionics  certification  project 

1 1 .4  Submit  updated  or  supplemental  information 

1 1 .5  Test  and  evaluate  for  certification 

1 1 .6  Issue  TSO  or  STC 


Participants  and  roles:  The  manufacturer  generally  initiates  the  certification  process  as  soon  as  a  new 
product  begins  to  emerge.  The  FAA  Aircraft  Certification  Office  (ACO)  has  the  role  of  reviewer  and 
approval  agent  and  the  two  parties  interact  until  certification  is  accomplished.  Some  new  equipment  and 
systems  involve  revolutionary  and  controversial  procedures  and  approvals  and  require  involvement  from 
other  parties,  such  as  the  Aircraft  Certification  Service  (AIR),  until  the  process  is  completed.  In  these 
cases,  issues  need  to  be  raised  across  FAA  LOBs  and  resolved.  The  Flight  Standards  Service  (AFS)  may 
need  to  be  involved  early  if  new  pilot  roles  and  procedures  are  created.  Interaction  with  Air  Traffic 
Services,  and  even  unions,  may  be  necessary  if  the  new  procedures  include  changes  in  air  traffic  control. 
Certification  plays  such  a  critical  role  that  it  affects  nearly  all  of  the  activities. 

Issues  and  risks:  Although  ADS-B  is  well  within  the  state  of  the  art,  the  use  of  this  technology  is  not  and 
it  may  suggest  a  change  to  the  traditional  partition  between  pilot  and  controller  roles  and  responsibilities. 
Since  the  uses  are  new  and  evolutionary,  certification  authorities  are  careful  and  want  to  limit  what  they 
certify.  They  are  wary  of  allowing  opportunities  to  extend  the  use  beyond  the  original  purpose  as  it  may 
foster  unsafe  situations. 

Interactions  with  other  categories:  While  the  Certification  category  precedes  and  feeds  directly  into  the 
Operational  Approval  category,  it  is  often  somewhat  self-contained,  with  limited  interactions  with  other 
categories.  There  is  some  involvement  with  Human  Factors,  Performance  and  Technical  Requirements, 
and  Safety  categories  for  equipment  that  permits  radically  new  and  more  controversial  procedures.  These 
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identiiy  detailed  avionics  design  requirements.  Unless  the  avionics  are  installed  on  an  aircraft  that  will  be 
operated  in  experimental  status,  avionics  certification  is  required  for  flight  evaluation  (Operational 
Evaluation  category). 

4.2.13  Category  12:  Operational  Approval 

Description:  This  category  deals  with  the  process  for  obtaining  FAA  approval  of  new  procedures.  This 
includes  FAA  Flight  Standards  approval  of  new  pilot  procedures  and  FAA  Air  Traffic  approval  of  new  air 
traffic  procedures. 

Flight  operations  are  governed  by  Federal  Aviation  Regulations  and  are  supplemented  by  Operations 
Specifications  (OpSpecs)  that  are  tailored  for  and  assigned  to  a  particular  operator.  These  OpSpecs  may 
Impose  additional  restrictions,  such  as  prohibiting  the  carriage  of  passengers  with  a  single  pilot,  while 
they  may  relax  other  regulatory  requirements.  Before  the  operator  can  use  new  procedures,  they  must  be 
formally  proposed,  examined  and  approved  by  FAA  Flight  Standards. 

The  operator  usually  starts  the  operational  approval  process  by  initiating  a  dialog  with  the  FAA. 

Examples  of  the  operator’s  purpose  for  requesting  operational  approval  could  be  to  employ  a  new  type  of 
instrument  approach,  to  initiate  flights  to  destinations  outside  the  continental  United  States,  or  to  have  the 
flight  crew  assume  new  roles  usually  reserved  for  air  traffic  control.  The  procedures  may  involve  the  use 
of  new  avionics. 


Following  an  informal  dialog  or  perhaps  a  statement  of  intent,  the  operator  makes  a  formal  application  to 
the  operator’s  Flight  Standards  District  Office  (FSDO)  for  operational  approval.  The  formal  submission 
must  contain  sufficient  information  for  the  FSDO  to  evaluate  the  new  procedures  and  to  determine  if  the 
new  procedures  can  be  conducted  safely.  Therefore,  the  application  must  contain  information  and 
approvals  for  any  new  equipment  to  be  used,  and  a  complete  description  of  the  new  procedures,  including 
training  plans  and  materials  for  the  flight  crew. 

Following  a  FSDO  review  of  the  proposal,  one  or  more  operational  demonstrations  may  be  required  and 
perhaps  a  validation  of  actual  training  sessions  as  well.  Once  the  safety  of  the  new  procedure  is 
substantiated,  the  FAA  would  issue  amended  OpSpecs  that  authorize  the  new  procedures. 

Air  traffic  procedures  are  governed  by  FAA  Orders  (such  as  71 10.65,  Air  Traffic  Control;  7210.3, 

Facility  Operations  and  Administration;  and  7610.2,  Special  Military  Operations).  Users  are  informed  of 
these  procedures  by  the  orders  themselves,  by  the  Aeronautical  Information  Manual  (AIM),  and,  for 
particular  operations  at  selected  locations,  by  letters  of  agreement  (LOAs).  Before  controllers  can  use 
new  procedures,  FAA  Air  Traffic  must  approve  them.  Usually,  this  requires  drafting  a  revised  version  of 
one  or  more  of  the  governing  ATC  documents,  coordinating  the  draft  via  a  formal  review  process,  and 
negotiating  a  formal  agreement  with  the  National  Air  Traffic  Controller  Association  (NATCA).  If  the 
proposed  change  involves  the  maintenance  of  FAA  equipment,  it  may  also  require  negotiating  a  formal 
agreement  with  the  Professional  Airway  Systems  Specialists  (PASS).  If  ground  systems  are  to  be 
integrated  into  the  NAS,  maintenance  training  will  be  required,  along  with  field  testing  and 
commissioning  of  these  systems. 


Activities: 


12.1  State  intent  to  conduct  new  flight  OPS  (phase  1) 

12.2  Request  operational  approval  (phase  2) 

12.3  Review  application  package  (phase  3) 

12.4  Demonstrate  operation  (phase  4) 

12.5  Grant  operational  approval  (phase  5) 

12.6  Revise  ATC  orders  &  LOAs 
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12.7  Revise  the  AIM 

12.8  Develop/perform  controller  training 

12.9  Coordinate  with  FAA  LOBs 

12.10  Inform  Unions 

12.11  Develop  maintenance  procedures 

12.12  Develop/perform  maintenance  training 

12.13  Field  test  ground  systems 

12.14  Commission  ground  systems 

Participants  and  roles:  The  air  carrier  operator  (such  as  an  airline,  air  charter  operator  or  cargo  airline) 
usually  initiates  the  process  for  operational  approval  of  new  pilot  procedures,  and  is  responsible  for 
submitting  all  documentation  and  sponsoring  the  training  and  changes  necessary  to  implement  the  new  or 
revised  operation.  The  Flight  Standards  District  Office  receives  the  application,  processes  and  approves 
the  new  procedure  or  involves  other  entities  to  resolve  issues.  The  Flight  Standards  Service  (AFS) 
becomes  involved  when  new  procedures  raise  contentious  issues  and  may  coordinate  with  other  FAA 
lines  of  business. 

Based  on  the  results  of  prior  development  and  evaluation,  the  Operational  Evaluation  Coordination  Group 
(OCG)  would  formally  propose  new  air  traffic  procedures.  FAA  Air  Traffic  would  develop  a  revised 
version  of  one  or  more  of  the  governing  ATC  documents,  coordinate  the  draft  document(s),  and  negotiate 
formal  agreements  with  FAA  unions.  FAA  Airway  Facilities  would  be  responsible  for  maintenance 
training,  procedures,  field  testing,  and  commissioning  of  any  ground  systems  to  be  incorporated  into  the 
NAS  to  support  the  applications. 

Issues  and  risks:  While  operational  approval  is  within  the  purview  of  the  Flight  Standards  Service,  the 
newly  proposed  procedures  may  require  a  transfer  of  roles  and  responsibilities  from  one  job  specialty  to 
another  and  require  extensive  coordination  with  other  entities  inside  and  outside  the  FAA.  These 
proposals  can  raise  wide-ranging  issues  with  unknown  outcome  from  safety  to  Job  security. 

Interactions  with  other  categories:  The  operational  approval  of  new  pilot  procedures  is  a  fairly  self- 
contained  effort,  with  few  interactions  with  other  activity  categories;  that  is,  most  interaction  is  between 
the  applicant  and  Flight  Standards.  Where  controversial  and  radically  new  procedures  are  involved,  there 
can  be  interactions  with  other  activities  such  as  Certification.  The  operational  approval  of  new  air  traffic 
procedures  and  testing/commissioning  of  ground  systems  is  also  a  fairly  self-contained  effort,  with  few 
interactions  with  other  categories;  that  is,  most  interaction  is  between  FAA  offices  or  between  FAA 
management  and  FAA  unions. 

4.2.14  Category  13:  Implementation  Transition 

Description:  This  category  addresses  those  activities  that  actually  involve  the  end-user  operational  use  of 
avionics  and  ground  systems  in  the  In-Service  phase.  This  includes  pilot/airline  use  of  avionics,  as  well  as 
FAA  controller/maintainer  use  of  ground  systems. 

Activities:  13.1  Operate  and  maintain  avionics 

13.2  Operate  and  maintain  ground  systems 

Participants  and  roles:  Pilots,  airlines,  AOCs,  and  possibly  third  parties  are  considered  to  be  the  end-user 
of  avionics  systems.  Manufacturers  and/or  end-users  are  responsible  for  the  maintenance  of  the  avionics. 
FAA  controllers  and  maintainers  are  the  primary  end-users  of  the  ground  systems,  except  where  these 
systems  are  required  to  support  airborne  applications.  The  FAA  is  responsible  for  the  maintenance  of  the 
ground  systems  in  the  NAS. 
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Issues  and  risks:  None  at  this  time. 


Interactions  with  other  categories:  The  activities  in  this  category  require  inputs  primarily  from  the 
Avionics  and  Ground  Systems  and  Operational  Approval  categories.  This  category  represents  the  end  of 
the  checklist  process,  and  so  there  are  no  significant  interactions  with  other  categories,  nor  are  there  any 
products  supplied  to  other  categories,  except  perhaps  in  the  form  of  lessons  learned  and/or  operational 
experience  that  can  be  transferred  to  the  activities  of  follow-on  application  development  processes. 


4.3  Phase  Summaries 

The  flow  of  activities  in  the  Checklist  can  be  described  in  terms  of  a  series  of  development  “phases”  as 
shown  in  Fig.  4-1.  The  scope  of  each  of  these  phases  is  described  in  the  following  sections. 
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4.3.1  Concept 

This  first  phase  addresses  the  development  of  high-level  operational  concepts  that  support  the  applieation. 
The  roadmap  outlining  the  nine  Free  Flight  Operational  Enhancements  that  provide  the  greatest  potential 
benefits  is  used  as  a  starting  point  for  this  phase  (as  well  as  the  SF21  program  as  a  whole).  High-level 
concepts  are  defined  for  specific  applications  identified  or  implied  by  the  roadmap.  FAA  and  Industry 
then  prioritize  these  specific  applications  to  identify  those  that  have  sufficient  priority  to  warrant  further 
action,  and  provide  guidance  toward  their  future  development  within  the  framework  of  the  roadmap. 

FAA  application  development  and  implementation  plans  (“Checklists”)  are  based  on  the  outcome  of  these 
activities. 

4.3.2  Development 

Once  an  application  has  been  identified  and  prioritized,  the  second  phase  addresses  the  development  of 
detailed  CONORS  and  detailed  systems  concepts  that  support  the  application  and  its  refinement  through 
initial  procedures  development,  human  factors  assessments,  safety  analyses,  system  and  interoperability 
assessments,  and  cost/benefits  assessments.  These  activities  culminate  in  the  development  of  draft 
procedures,  system  performance  requirements,  cost/benefits  estimates,  and  detailed  systems  and  Ops 
concepts. 

At  this  point,  the  FAA  and  Industry  determine  if  development  has  progressed  to  the  point  where  selected 
(limited)  aspects  of  the  application  can  be  operationally  evaluated,  and  if  resources  can  and  should  be 
expended  to  conduct  such  an  evaluation.  A  “Yes”  decision  allows  the  application  to  progress  to  the  next 
phase.  Limited  Evaluation.  A  “No”  decision  either  returns  the  application  to  some  point  in  the 
Development  phase  (for  further  development)  or  eliminates  the  application  from  further  development. 

4.3.3  Limited  Evaluation 

This  phase  addresses  the  evaluation  of  selected  (limited)  aspects  of  the  application  in  both  simulated  and 
live  operational  environments,  considering  benefits,  procedures,  human  factors,  system  performance, 
safety,  certification,  and  operational  issues  in  the  evaluation.  Limited  evaluation  is  performed  when 
application  concepts  have  not  yet  fully  matured,  but  whose  development  requires  certain  simulated  and 
live  operational  assessments  to  be  conducted.  In  some  cases,  a  limited  evaluation  of  an  application  may 
not  be  necessary,  in  which  case  the  application  may  progress  directly  to  the  Full  Evaluation  phase. 

Once  a  determination  is  made  that  an  application  requires  a  Limited  Evaluation,  the  FAA  and  Industry 
make  preparations  for  selected  simulated  and  operational  assessments  (usually  in  conjunction  with  similar 
assessments  for  other  applications).  This  includes  coordination  among  the  various  FAA  and  Industry 
organizations  that  have  responsibility  for  specific  activities  such  as  procedures,  human  factors,  safety, 
cost/benefits,  system  performance,  avionics  and  ground  systems  (for  test),  certification,  and  operational 
approvals,  as  required.  Once  preparations  are  complete,  simulations  and  assessments  are  conducted  on 
selected  aspects  of  the  application.  These  assessments  culminate  in  the  refinement  of  draft  procedures, 
system  performance  requirements,  cost/benefits  estimates,  and  detailed  systems  and  Ops  concepts. 

At  this  point,  the  FAA  and  Industry  determine  if  development  has  progressed  to  the  point  where  all 
aspects  of  the  application  are  ready  to  be  (fully)  operationally  evaluated,  and  if  resources  can  and  should 
be  expended  to  conduct  such  an  evaluation.  A  “Yes”  decision  allows  the  application  to  progress  to  the 
next  phase.  Full  Evaluation.  A  “No”  decision  either  returns  the  application  to  an  earlier  phase  of 
development  (Limited  Evaluation  or  Development),  or  eliminates  the  application  from  further 
development.  It  should  be  noted  that  many  applications  may  require  more  than  one  pass  through  a 
Limited  Evaluation  phase  before  they  are  ready  to  progress  to  the  Full  Evaluation  phase. 
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4.3.4  Full  Evaluation 


This  phase  addresses  the  evaluation  of  all  aspects  of  the  application  in  both  simulated  and  live  operational 
environments,  considering  benefits,  procedures,  human  factors,  system  performance,  safety,  certification, 
and  operational  issues  in  the  evaluation.  Full  Evaluation  is  performed  when  an  application  has  fully 
matured  and  requires  the  validation  of  application  concepts  before  stakeholder  commitments  could  be 
obtained. 

Once  a  determination  is  made  that  an  application  is  ready  for  Full  Evaluation,  preparations  for  full 
simulated  and  live  operational  assessments  are  made  (usually  in  conjunction  with  similar  assessments  for 
other  applications).  This  includes  coordination  among  the  various  FAA  and  Industry  organizations  that 
have  responsibility  for  specific  activities  such  as  procedures,  human  factors,  safety,  cost/benefits,  system 
performance,  avionics  and  ground  systems  (for  test),  certification,  and  operational  approvals,  as  required. 
Once  preparations  are  complete,  full  simulations  and  live  assessments  are  conducted  on  the  application. 
The  goal  is  to  collect  sufficient  data  to  support  Post-Evaluation  analyses. 

4.3.5  Post-Evaluation 

Based  on  the  results  of  Full  Evaluation  and  application  development  to  date,  Post-Evaluation  final 
assessments  and  validations  are  performed  in  preparation  for  stakeholder  decisionmaking.  These 
assessments  culminate  in  the  final  revision  of  draft  procedures,  system  performance  requirements, 
cost/benefits  estimates,  and  detailed  systems  and  Ops  concepts.  At  this  point,  the  FAA  and  Industry 
determine  if  the  evaluations  have  been  adequate  such  that  all  significant  issues  have  been  addressed.  A 
“No”  decision  either  returns  the  application  to  an  earlier  phase  of  development  (Full  Evaluation,  Limited 
Evaluation,  or  Development),  or  eliminates  the  application  from  further  development. 

If  “Yes”,  the  FAA  then  determines  if  it  will  commit  to  implementing  the  application,  should  there  be 
sufficient  user  commitment  to  pursue  operational  approval  of  the  application.  Likewise,  the  users  develop 
business  cases  to  determine  if  they  will  commit  to  pursuing  operational  approval  of  the  application,  given 
an  FAA  commitment  to  do  the  same.  A  “No”  decision  for  either  case  either  returns  the  application  to  an 
earlier  phase  of  development,  or  eliminates  the  application  from  implementation.  A  “Yes”  decision  for 
both  cases  allows  the  application  to  progress  to  the  next  phase. 

4.3.6  Investment  Analysis 

Should  the  application  require  ground  infrastructure,  the  FAA  must  perform  an  investment  analysis  prior 
to  determining  its  commitment  to  implement  the  application  (most  likely  bundled  along  with  other 
applications  that  would  also  require  ground  infrastructure).  In  this  case,  the  FAA’s  commitment,  should 
it  be  forthcoming,  would  be  represented  by  an  Investment  Decision  as  defined  in  the  acquisition 
management  system  (AMS).  This  Investment  Decision  would  only  be  made  with  the  understanding  that 
users  would  also  commit  to  pursuing  operational  approval  of  the  application(s). 

4.3.7  Step-Up 

In  this  phase,  once  the  FAA  and  the  users  both  commit  to  the  application,  users  “step-up”  by  applying  for 
operational  approval  for  the  application,  while  the  FAA  “steps-up”  by  drafting  ATC  procedures  (if 
necessary).  The  FAA  also  works  with  the  users  to  certify  avionics  and  move  the  application  through  the 
formal  operational  approval  process  in  a  timely  fashion. 
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Based  on  final  system  performance  requirements  (preferrably  in  the  form  of  standards),  avionics  vendors 
develop  their  certification  packages  and  submit  them  to  the  FAA  for  review  and  approval.  Likewise, 
based  also  on  final  draft  procedures,  cost/benefits  estimates,  and  detailed  systems  and  Ops  concepts,  users 
develop  their  operational  approval  packages  and  submit  them  to  the  FAA  for  review.  The  FAA  initiates 
the  process  for  modifying  or  adding  ATC  procedures  required  to  support  the  application.  Should  the 
application  require  ground  infrastructure,  the  FAA  would  establish  program  baselines,  develop  and  award 
contracts,  and  develop  production  systems  in  accordance  with  the  AMS. 

The  FAA  and  the  labor  unions  affected  by  the  application  then  develop  the  formal  agreements  necessary 
to  implement  the  application,  based  on  union  involvement  throughout  the  development  process.  A  “No” 
decision  either  returns  the  application  to  an  earlier  phase  of  development  or  pre-approval,  or  eliminates 
the  application  from  possible  approval  altogether.  A  “Yes”  decision  allows  the  application  to  progress  to 
the  next  phase.  Implementation. 

4.3.8  Implementation 

In  this  phase,  the  FAA  finalizes  the  proper  procedures  and  regulatory  documentation,  and  integrates  the 
required  ground  systems  at  the  first  site  into  the  NAS.  This  process  starts  with  the  manufacture  of  ground 
systems,  followed  by  field  testing  and  an  FAA  In-Service  decision.  Once  a  positive  In-Service  decision  is 
made,  the  FAA  can  then  commission  the  ground  systems  for  operational  use,  and  approve  (Air  Traffic, 
Flight  Standards)  the  application  for  operational  use  at  the  first  site  by  the  user(s). 

4.3.9  Transition 

This  phase  consists  primarily  of  waterfall  ground  system  installations,  commissionings,  and  operational 
approvals  (both  air  and  ground)  beyond  the  first  site  implementation.  These  approvals  could  conceivably 
be  limited  to  specific  pockets  of  implementation,  or  may  be  fleet-wide  or  nation-wide. 

4.3.10  In-Service 

The  final  phase  of  development  and  implementation  represents  the  actual  operational  use  of  the 
application  in  the  NAS,  the  maintenance  of  the  equipment  required  to  support  the  application  (e.g., 
avionics  and  ground  systems),  and  any  recurring  training  required  (operator,  maintainer,  controller). 
Operational  experience  and  data  accumulated  during  this  phase  can/may  feed  into  the  development  and 
implementation  cycle  of  other  applications,  or  future  variations  of  the  current  application. 

4.4  Checklist  Flow  Chart 

Figure  4-2  shows  the  primary  relationships  between  the  70  activities,  7  management  tasks,  and  13  key 
decisions  required  to  develop  and  implement  the  applications  described  in  Section  3.  Each  activity,  task 
and  decision  is  described  in  detail  in  Section  5. 

Activity  categories  in  the  chart  appear  horizontally,  while  development  phases  appear  vertically.  Each 
box  in  the  chart  represents  a  single  activity,  with  a  numeric  identification  (ID)  representing  the  detailed 
description  of  that  activity  (much  like  a  work  breakdown  structure).  Lines  connecting  boxes  represent 
major  dependencies  between  different  activities.  Vertical  dotted  (blue)  lines  represent  key  decisions,  and 
red  arrows  represent  dependencies  from  activities  to  these  decisions. 

Activity  IDs  are  annotated  with  the  phase  in  which  the  activity  is  performed.  For  example,  IDs  for 
activities  in  the  Concept  phase  are  annotated  as  “con.”  IDs  for  activities  in  the  Development  phase  are 
annotated  as  “dev.”  IDs  for  activities  in  the  Limited  Evaluation  phase  are  annotated  as  “lim”.  IDs  for 
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activities  in  the  Full  Evaluation  are  annotated  as  “full”.  IDs  for  activities  in  the  Post-Evaluation  phase  are 
annotated  as  “post.”  IDs  for  activities  in  the  Investment  Analysis  phase  are  annotated  as  “lA.”  IDs  for 
activities  in  the  Step-Up  phase  are  annotated  as  “step.”  IDs  for  activities  in  the  Implementation  phase  are 
annotated  as  “imp.”  IDs  for  activities  in  the  Transition  phase  are  annotated  as  “tra.”  IDs  for  activities  in 
the  In-Service  phase  are  annotated  as  “ins”.  IDs  for  ongoing  activities  that  span  multiple  phases  are  not 
annotated. 

When  an  activity  is  repeated  in  several  phases,  it  is  understood  that  the  work  performed  in  later  phases 
will  use  the  products  of  earlier  phases  as  inputs.  For  example,  if  Activity  6.1  in  the  Concept  (con)  phase  is 
repeated  in  the  Development  (dev)  phase,  the  work  performed  in  the  “dev”  phase  (6.1  dev)  will  have 
available  to  it  the  output  product  of  the  “con”  phase  (6. 1  con).  Likewise,  it  is  also  understood  that  if  the 
output  of  “6.1  lim”  is  provided  as  an  input  to  Activity  4.5  in  the  Full  Evaluation  phase  (4.5  full),  then 
“4.5  full”  will  have  available  to  it  as  inputs  the  products  of  not  only  “6.1  lim”  but  also  “6.1  con”  and 
“6.1  dev.”  Thus,  for  the  simplicity  of  presentation,  only  direct  dependencies  between  different  activities 
are  explicitly  shown  in  the  flowchart  and  in  the  detailed  activity  descriptions.  Dependencies  between 
different  phases  of  the  same  activity  and  second-order  dependencies  between  activities  are  not  explicitly 
identified. 
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5.  DETAILED  ACTIVITY  DESCRIPTIONS 


5.1  Outline 

Section  5.2  contains  a  detailed  description  of  each  of  the  activities,  tasks,  and  key  decisions  represented  in 
Figure  4-2.  Each  description  contains  the  following: 

•  Description  of  the  activity 

•  Organization(s)  responsible  for  planning  or  performing  the  activity 

•  Organization(s)  responsible  for  approving  or  accepting  the  results  of  the  activity,  or  for  making 
the  decision 

•  Products  generated  by  the  activity 

•  Issues  to  be  addressed 

•  Schedule:  Estimated  start  date,  duration,  and  level  of  effort 

•  Inputs  needed  from  other  activities  to  accomplish  this  activity 

•  Interactions  with  other  activities  being  done  at  the  same  time 

•  Outputs  from  this  activity  that  will  be  used  as  inputs  to  other  activities 

Input,  interaction,  and  output  dependencies  for  each  activity  are  presented  in  tabular  format,  with 
references  to  the  phases  in  which  the  required  inputs  become  available,  interactions  occur,  or  outputs  are 
generated.  Figure  5-1  provides  a  graphical  explanation  on  how  to  interpret  the  Input,  Interaction,  and 
Output  dependency  tables  in  the  detailed  activity  descriptions, 

5.2  Detailed  Activity  Descriptions 

Detailed  activity  descriptions  and  the  associated  interaction  tables  are  shown  on  the  pages  following 
Figure  5-1. 
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Related  activity 
providing  input 


Related  activity’s 
input  product 


Subject  activity 


Phase(s)  in  which  related 
activity’s  input  product 
becomes  available 


Phase(s)  in  which  input 
product  is  used^  by 
subject  activity _ 


Dependencies  and  phases  of  2.1  Plan  cost/ben^f^nalyses 

/  \  Post-Eval  “I  p  Im^tment  Analysis 

/  yullEval. -|  /sWup  / 

/  Limited  Eval.  -i  /  jr  Irnp|ementmion 

/  Development  ^  p  Trhj^ion 

/  ConcepA-i  , [  t/li^ervice 

/  Input  from  Activity:  ■  yH  \ 


I  Description  of  product  use 


1.1  Define  High-Level  CONOPS  ^  \  ^  . . ' . 


i^h-level  concept  provides  guidance  for  cost  and  benefits  analyses. 


\  Input  via  Product: 


1.1.1  High-Level  CONOPS 


Related  activity  being 
interacted  with 


Phase(s)  in  which 
interaction(s)  occur 


Description  of  interaction 


iteract  with  Activity:  _ 


0.1  Develop  &  Revise  SF21  MP 


Hannins  cost/benefit  analyses  provides  insight  into  refinements  to  the  SF21  Master  Plan,  and  vice  versa 


0.2  Develop  &  Revise  Checklist  |  ^ 


Vanning  cost/benefit  analyses  provides  insight  into  refinements  to  the  Checklist,  and  vice  versa 


Subject  activity’s 
output  product 


Related  activity 
receiving  output 


Phase(s)  in  which  subject 
activity’s  output  product 
becomes  available 


Phase(s)  in  which  output 
product  is  used^  by  the 
related  activity 


Description  of  product  use 


- f - - - 

2.1.1  CBA  Plan 

■ 

- - - 

2.2  Analyze  Costs 

\The  CBA  plan  provides  guidance  for  cost  analyses. 

2.1.1  CBA  Plan 

i;i!  \ii  i  i  1  1 

2.3  Analyze  Benefits 

The  CBA  plan  provides  guidance  for  benefits  analyses. 
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Overview  of  Activity  0.1:  Develop  and  Revise  SF21  MP 

Description:  Develop,  coordinate,  and  reach  consensus  on  the  Safe  Flight  21  Master  Plan.  [Note:  OpEval 
planning  documents  will  be  developed  in  conjunction  with  Activity  10.1]. 

The  Safe  Flight  21  (SF21)  Master  Plan  will  characterize  the  status  of  all  Checklist  activities  as  appropriate.  In 
particular,  the  SF21  Master  Plan  will  characterize  the  various  key  decisions  (3.1  thorough  3.7)  and  the  other 
management  tasks  (0.2  through  0.5). 

This  task  is  performed  collectively  for  all  applications. 

Plan  and  Perform:  SF21  Program  Office  POC  =  SF21  Progam  Lead 

Approve  or  Accept:  SF21  Steering  Group  POC  =  SF21  StG  Co-chaire 

Products: 

0.1.1:  Safe  Flight  21  Master  Plan:  This  product  includes  the  periodic  revision  of  the  Master  Plan  (MP). 
Issues: 

-  With  industiy  pushing  for  a  very  aggressive  schedule,  there  is  a  risk  that  the  published  schedule  may  be 
unrealistic 

-  Sequencing  and  flow  of  applications  (collectively)  through  development,  evaluation,  and  transition 


Schedule: 


Con 

Dev 

Lim 

Fuir 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

12 

12 

12 

12 

12 

12 

12 

8 

4 

LoE  (sm) 

28 


Safe  Flight  21  Generic  Application  Checklist  -  September  28,  2001 


Dependencies  and  Phases: 


F 

Lim 
Dev 
Con 


Input  from  Activity: 


3.1:  Decision  -  Select  Enhancements 
3.2:  Decision  -  Select  &  Prioritize  Apps 


Input  via  Product: 


3.1.1:  Roadmap  for  Free  Flight 
Operational  Enhancements 
3.2.1:  Application  Target  Schedule 


Roadmap  things p  be  addressed  in  th^  Qvigiml  SFJl  Master  Plan.  Decision(s)  w//  impact  the, 

contentsdf  the  document (s).  -  ^  ;  .-to-. 


3.3:  Decision  -  Go  for  Limited  1  |  1 3  | 

Evaluation  _ ^ _ ^ 

_  ^  ^ . ^ . . 

Decision(s)  will  impact  the  contents  of  the  documeni(sfy  -  ^  ; :  ■  A  ^  ^  \ ;  r.:;i 


3.3.1:  Decision  to  Undertake  Limited 
Evaluation 
13.4.1:  Link  Decision 


3.5:  Decision  -  Go  for  Full  Evaluation 
3.6:  Decision  -  Mission  Need 


Decision(s)  will  impact  the  contents  €fthe  doeument(s)r 


3.7:  Decision  -  Was  OpEval  Adequate? 


DeQision(s)  will  impact  the  contents  of  the  document(sf  ■  ^  ‘ 


3.8:  Decision  -  Initial  Investment 
3.9:  Decision  -  Industry  Commits  to  I .  L 

Impl. 

3.10:  Decision  -  Sel.  Vendor  &  Award 
Contract  : 

3.11;  Decision  -  Final  Investment  ■ 

Decision(s)  will  impact  the  contents  of  the  document(s)7 


3.12:  Decision  -  Formal  FAAAJnion 
Agreement 

3,13:  Decision  -  In-Service 
12.5:  Grant  Operational  Approval  (Ph.  ^  ' 

5 _ _ _ '' aSIIP* 

Decision(s)  will  impact  the  contents  of  the  document(s). 


3.5.1:  Decision  to  Plan  for  Full 
Evaluation 

3.6.1:  Mission  Need  Decision 


3.7.1:  OpEval  Adequacy  Decision 


3.8.1:  Initial  Investment  Decision 
3.9.1:  Formal  Notice  from  Applicants 
3.10.1:  Contract  Award 
3.11.1:  Final  Investment  Decision 


3.12.1:  FAA/Union  Agreement 
3.13.1:  In-Service  Decision 
12.5.1:  Operational  Approval 


Interact  with  Activit 


0.2:  Develop  and  Revise  Checklist  MM 
0.3:  Manage  Issues  and  Risks  II 

0.4:  Administer  SF21  Program  [’ 

May  identify  changes  needed  (and  vice  versa). 


1.1:  Define  High-Level  Concept  m 

1.6:  Develop  Research  Evaluation  Plan  pQ| 
2.1:  Plan  Cost/Benefit  Analyses 


1  I2I3I4I5I6I7I8I9I0I 


’A- 5.. 


I"# 

XvA' '  AV'  “''V 


4.1:  Plan  Procedure  Development 
5.1:  Plan  Human  Factors  Activities 
8.1:  Plan  Coord.  Safety  Activities 

Provides  insight  into  refinement  of  interacting  activity  products  and  vice  versa.  ' 


>  .  .  . i'" « '  A*':  ^  \  ‘  '■  \  ^  V S'** 


'c  ”  ™  i,  v <\' A;  r«  .V  'si g';-' ' '  ’  “  *  w  s-,- s  - 
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1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 
1.4:  Identify  Synergistic  Applications 
Sets 


2  3 


A 


.  -S! 


, ... 


Provides  insight  into  refinement  of  interacting  activity  products  md  ncelyei:sd  j^^^^^^ 


fliiii 


10.1:  Plan  Joint  Evaluations 


314 


Hi 


Provides  insight  into  refinement  of  interacting  activity  products  and  vice  versa/ 


Output  via  Product: 

^11 

n 

3:4H 

6 

Hi 

H 

HH 

Output  to  Activity: 

0.1.1:  Saffe  Flightil  M 

m. 

i 

0.5:  Coordinate  for  Decisions 

iJ 

31.4.1.516 

|7!8|  1 

J 

Provides  partial  basis  for  decisions. 
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0.2:  Develop  and  Revise  Checklist 


Description:  Develop  and  revise  a  ehecklist  for  an  applieation  or  group  of  related  applieations.  The  Checklist  is 
to  describe  all  Level  2  activities  that  are  required  before  the  FAA  and  Industry  could  make  a  decision  to 
implement  for  operational  use  of  particular  application(s).  The  development  and  revision  of  the  Checklist 
activities  will  consider  as  appropriate  all  of  the  Checklist  activities.  In  particular,  the  Checklist  will  consider 
the  various  key  decisions  (3.1  thorough  3.7)  and  the  other  management  tasks  (0.1  and  0.3  through  0.5). 

Plan  and  Perform:  Checklist  Team  POC  =  Checklist  Team 


Approve  or  Accept:  FAA  Lines  of  Business 


POC  =  Various 


Products: 

0.2.1:  Checklist:  A  detailed  listing  of  all  the  Level  2  activities  that  must  be  accomplished  before  the  aviation 
community  can  decide  whether  an  Application  should  be  implemented  for  operational  use.  This  product  will 
be  revised  as  needed. 


Issues: 

-  The  complexity  of  Checklist  may  put  people  off 

-  Selection  of  applications  for  special  attention 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

24 

16 

16 

16 

16 

16 

16 

16 

12 

8 

LoE  (sm) 
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3.1:  Decision  -  Select  Enhancements 
3.2:  Decision  -  Select  &  Prioritize  Apps 


Decision(s)  will  impact  the  contents  of  the 


3.3:  Decision  -  Go  for  Limited  1 3 

Evaluation  _ 

3.4:  Decision  -  Select  Link(s) 

Decision(s)  will  impact  the  contents  of  the  docutnent(s),  \  ; 


4 


3,5:  Decision  -  Go  for  Full  Evaluation 
3.6:  Decision  -  Mission  Need 


i: 


Decision(s)  will  impact  the  contents  of  the  document(s). 


3.7:  Decision  -  Was  OpEval  Adequate' 


Decision(s)  will  impact  the  contents  of  the  document(s)l 


3.8:  Decision  -  Initial  Investment  _ 

3.9:  Decision  -  Industry  Commits  to 
Impl. 

3.10:  Decision  -  Sel.  Vendor  &  Award  ‘ 

Contract 

3.11:  Decision  -  Final  Investment 

Decision(s)  will  impact  the  contents  of  the  document^): 


3.12:  Decision  -  Formal  FAA/Union  _ 

Agreement  --  I-  1  I 

3.13:  Decision  -  In-Service  t:" 

12.5:  Grant  Operational  Approval  (Ph.  : !  if 
5)  ■ 

Decision(s)  will  impact  the  contents  of  the  docuimeni(s)r' 


3.1.1:  Roadmap  for  Free  Flight 
Operational  Enhancements 
3.2,1:  Application  Target  Schedule 


3.3.1:  Decision  to  Undertake  Limited 

Evaluation 

3.4.1:  Link  Decision 


3.5.1:  Decision  to  Plan  for  Full 
Evaluation 

3.6.1:  Mission  Need  Decision 


3.7.1:  OpEval  Adequacy  Decision 


3.8.1:  Initial  Investment  Decision 
3.9.1:  Formal  Notice  from  Applicants 
3.10.1:  Contract  Award 
3.11.1:  Final  Investment  Decision 


3.12.1:  FAA/Union  Agreement 
3.13.1:  In-Service  Decision 
12.5.1:  Operational  Approval 


Interact  with  Activit 


0.1:  Develop  and  Revise  SF21  MP  Mi J  2 

0.3:  Manage  Issues  and  Risks  pQO 

0.4:  Administer  SF21  Program 

May  identify  changes  needed  (and  vice  versa) :  f 


1.1:  Define  High-Level  Concept  1 

1.6:  Develop  Research  Evaluation  Plan 
2.1:  Plan  Cost/Benefit  Analyses 
4.1:  Plan  Procedure  Development 
5.1:  Plan  Human  Factors  Activities 
8.1:  Plan  Coord.  Safety  Activities  | 


' -"I 


Provides  insight  into  refinement  of  interacting  activity  products  and  vice  versa 
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1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 
1.4:  Identify  Synergistic  Applications 
Sets 


Output  via  Product: 


0.2.1;  Checklist 

Provides  partial  basis  for  decisions. 


2  3  4  5  6  7  8 
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0.3:  Manage  Issues  and  Risks 


Description:  Manage  the  issues  and  risks  of  all  Safe  Flight  21  activities  and  implement  risk  management 

controls  to  insure  success  of  the  program.  The  Management  of  Issues  and  Risks  Task  will  interact  with  all  of 
the  Checklist  activities  as  appropriate. 

Plan  and  Perform:  SF21  Program  Office  POC  =  SF21  Progam  Lead 

Approve  or  Accept:  FAA  Lines  of  Business  POC  =  Various 

Products: 

0.3.1:  Risk  Management  Plan:  A  plan  that  outlines  the  risk  management  processes  that  will  identify  and 
assess  risk  areas,  develop  and  execute  risk  mitigation  or  elimination  strategies,  track  and  evaluate  mitigation 
efforts,  and  continue  mitigation  activity  until  risk  is  eliminated  or  its  consequences  reduced  to  acceptable 
levels. 

0.3.2:  Issues  and  Resolutions  Document: 

0.3.3:  Risk  Analysis  Reports: 

0.3.4:  Risk  Mitigation: 

Issues: 


-  The  complexity  and  interactions  between  various  applications  will  make  it  difficult  to  identify  and  control 
all  of  the  risks 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

999 

999 

999 

999 

999 

999 

999 

999 

999 

999 

LoE  (sm) 
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Dependencies  and  Phases: 


F 

Urn 

Dev-i 

Con 


September  28,  2001 


Input  from  Activit 


3.1:  Decision  -  Select  Enhancements 
3.2:  Decision  -  Select  &  Prioritize  Apps 

^I>ecision(s)  will impact  the  contents  cfthe^d^ 

3.3:  Decision  -  Go  for  Limited  | 

Evaluation  _ 

3.4:  Decision  -  Select  Link(s)  "  ;  .  :  ;  ! 

Decision(s)  will  impact  t^^^^  document(s): 


3.5:  Decision  -  Go  for  Full  Evaluation  ^ 

3.6:  Decision  -  Mission  Need 


Input  via  Product:  _ 


3.1.1:  Roadmap  for  Free  Flight 
Operational  Enhancements 
3.2.1:  Application  Target  Schedule 

3.3.1:  Decision  to  Undertake  Limited 

Evaluation 

3.4.1:  Link  Decision 


3.5.1:  Decision  to  Plan  for  Full 
Evaluation 

3.6.1:  Mission  Need  Decision 


RSI 


Decision(s)  yvUl  impact  the  contents  of  the  document^)'. " 


3,7:  Decision  -  Was  OpEval  Adequate' 


Decision(s)  mil  impact  the  contents  of  the  document(sf~ 


3,8:  Decision  -  Initial  Investment  _ 

3,9:  Decision  -  Industry  Commits  to 
Impl, 

3,10:  Decision  -  Sel,  Vendor  &  Award 

Contract  iSHSlilili 

3,11:  Decision  -  Final  Investment  :  Vv 

Decision(s)  will  impact  the  contents  of  the  document(s): 


3.12:  Decision  -  Formal  FAA/Union 
Agreement 

3.13:  Decision  -  In-Service 
12.5:  Grant  Operational  Approval  (Ph, 

5) _ . ' 

Decision(s)  will  impact  the  contents  of  the  documentfs). 


3.7.1:  OpEval  Adequacy  Decision 


3.8.1:  Initial  Investment  Decision 
S  3.9.1:  Formal  Notice  from  Applicants 
3.10.1:  Contract  Award 
:  3.11.1:  Final  Investment  Decision 


3.12.1:  FAA/Union  Agreement 
3.13.1:  In-Service  Decision 
12.5.1:  Operational  Approval 


Interact  with  Activit 


0.1:  Develop  and  Revise  SF21  MP  III.  ^ . 

0.2:  Develop  and  Revise  Checklist  11 2  7  9l[|| 

0.4:  Administer  SF21  Program  1  , 

May  identify  changes  needed  (and  vice  versa):  ^  "  -  ,  ;  \  ; 


0.6:  Develop  Acquisition  Program  Plans 
12.9:  Coord  w/ FAA  LoBs 

May  identify  changes  needed  (and  vice  versa).  ' ,  '  "  -  ?  ' 


1.1:  Define  High-Level  Concept  111  .  I,  ' 

1.6:  Develop  Research  Evaluation  Plan  il  I  K  h  I  I  111-;  C  r 
2.1:  Plan  Cost/Benefit  Analyses  /  \  \  <  :?  y 

4.1:  Plan  Procedure  Development  \ 

5.1:  Plan  Human  Factors  Activities  \ 

8.1:  Plan  Coord.  Safety  Activities 

Provides  insight  into  refinement  of  interacting  activity  products  and  vice  vefsa^ 


MlSIil 
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8.5:  Track  Safety  Issues  During  Dev't 


May  identify  changes  needed  (and  vice  versa). 


1  2  3i4i 
2 


8.6:  Ensure  Safety  of  Testing 
10.1:  Plan  Joint  Evaluations 


3|4|  i 

tt 

□ 

□ 

□ 

■  -  ' '  '• 


Incorporates  safety  and  other  issues  into 
versa). 


(arukice.  ” 


7 

’ . . . .  ■  <;  ««T 


11.3:  Estab.  Avionics  Cert.  Project 
12.3:  Review  Application  Package  (Ph. 
3) 


. [ . 


May  identify  changes  needed  (and  vice  versa) 
12.13:  Field  Test  Ground  Systems 


I  I  *1'\  '  r  >'  'I  '  f  '  <i>  »  >S  . . *  t  <*..  wi.!,  >  '« 


May  identify  changes  needed  (and  vice  yersa),' 


. 

. 

Output  via  Product: 


0.3.1:  Risk  Management  Plan 
0.3.2:  Issues  and  Resolutions  Document 
0.3.3:  Risk  Analysis  Reports 
0.3.4:  Risk  Mitigation  , . 

Provides  pa}-tial  basis  for  decisions. 


Output  to  Activity: 


0.5:  Coordinate  for  Decisions 
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0.4:  Administer  SF21  Program 


Description:  Administer  all  aspects  of  the  Safe  Flight  21  program.  Develop,  award,  and  manage  the  contracts 
needed  to  support  the  program  office  and  the  operational  evaluations.  Manage  all  budgetary  matters  and 
resource  allocation. 

The  Administration  of  SF21  Program  Task  will  interact  with  or  serve  as  an  input  to  all  of  the  Checklist 
activities  as  appropriate.  In  particular,  the  Administration  of  SF21  Program  Task  will  serve  as  an  input  to  the 
various  key  decisions  (3.1  thorough  3.7)  and  the  other  management  tasks  (0.1,  0.2,  0.3,  and  0.5).  For 
simplicity  of  presentation,  the  key  decisions  and  the  other  management  tasks  are  NOT  shown  in  the  following 
interaction  tables. 

Plan  and  Perform:  SF21  Program  Office  POC  =  Various 

Approve  or  Accept:  SF2 1  Program  Office  POC  =  SF2 1  Progam  Lead 

Products: 

0.4.1:  Annual  Budgetary  Documents: 

0.4.2:  Contracts  to  Support  Evaluations: 

0.4.3:  Contracts  to  Support  SF21  Program  Office: 

0.4.4:  Resource  Allocation  Decisions: 

Issues: 

-  With  the  many  different  players  involved  in  this  program  with  all  of  their  various  agendas,  the  program 
needs  to  be  flexible  and  responsive;  there  is  a  risk  that  resource  limitations  and  contractual  constraints  may  limit 
our  ability  to  modify  the  program  quickly  when  the  need  arises 

Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

999 

999 

999 

999 

999 

999 

999 

999 

999 

999 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-, 
Lim  -I 
Dev  -| 

Con  —1  I 


Input  from  Activity: 


3.1:  Decision  -  Select  Enhancements 
3.2:  Decision  -  Select  &  Prioritize  Apps 


■ 

L 

IL 

,  . 

Decision(s)  will  impact  the  contents  of  the  document  (s). 


3.3:  Decision  -  Go  for  Limited  _ i  3  I  I 

Evaluation  _ 

3.4:  Decision  -  Select  Link(s) 


Decision(s)  will  impact  the  contents  of  the  document  (s). 


3.5:  Decision  -  Go  for  Full  Evaluation  ^ 

3.6:  Decision  -  Mission  Need  | 

Decision(s)  will  impact  the  contents  of  the  documehi(s). 


-  Step 
p  Imp 
Tra 

I  r'ns 

H  Input  via  Product: _ 


_ 3.1.1:  Roadmap  for  Free  Flight 

.J:-.  Operational  Enhancements 
j  j  3.2.1:  Application  Target  Schedule 


_ 3.3.1:  Decision  to  Undertake  Limited 

•  Evaluation 

3.4.1:  Link  Decision 


3.5.1:  Decision  to  Plan  for  Full 
zL  Evaluation 
,  3.6.1:  Mission  Need  Decision 


■■■■■■I 

■■■■■■ 


3.7:  Decision  -  Was  OpEval  Adequate' 


Decision(s)  will  impact  the  Contents  of  the  document  (sf^ 


3.8:  Decision  -  Initial  Investment  _ 

3.9:  Decision  -  Industry  Commits  to  1:^^... 

Impl. 

3.10:  Decision  -  Sel.  Vendor  &  Award 
Contract 

3.11:  Decision  -  Final  Investment  : 

Decision(s)  will  impact  the  contents  of  the  document(s). 


3.12:  Decision  -  Formal  FAA/Union  _ 

Agreement  :l  d 

3.13:  Decision  -  In-Service  - 

12.5:  Grant  Operational  Approval  (Ph.  . '  ^  '1, 

5) _ _ _ 1; 

Decision(s)  will  impact  the  contents  of  the  ddcument(s)yv^i 


iWifllfiiSi* 


3.7.1:  OpEval  Adequacy  Decision 


3.8.1:  Initial  Investment  Decision 
3.9.1:  Formal  Notice  from  Applicants 
3.10.1:  Contract  Award 
3.11.1:  Final  Investment  Decision 


3.12.1:  FAA/Union  Agreement 
3.13.1:  In-Service  Decision 
12.5.1:  Operational  Approval 


0.1 :  Develop  and  Revise  SF21  MP  L-  ^  lJJ-I  ^  ■  ■  ' "  '  '■ ' 

0.2:  Develop  and  Revise  Checklist  ■■  7.  7  9  111 

0.3:  Manage  Issues  and  Risks  |  .  ^  /  .-i.  r-'-'S  ■  p:',;.',':-?'/ 

May  identify  changes  needed  (and  viceyersaf  ..  va,v!:!i. 


Interact  with  Activi 


0.6:  Develop  Acquisition  Program  Plans 


SF21  program  management iwill  ttffeci  development 


1.1:  Define  High-Level  Concept  MM _ _ _ . 

1.6:  Develop  Research  Evaluation  Plan  Pi  ^  iXIl 

2.1:  Plan  Cost/Benefit  Analyses  '  'i"'  V  . 

4.1:  Plan  Procedure  Development  .I/,! 

5.1:  Plan  Human  Factors  Activities  •■/'■a  'i' '' ^ 

8.1:  Plan  Coord.  Safety  Activities  '-i 

Provides  insight  into  refinement  of  interacting  activity  products  and  vice  versaiiz 
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10.1:  Plan  Joint  Evaluations  1—4 

. . . .  .  . . 

May  identify  changes  needed  (and  vice  versa). 


OutDut  via  Product: 


0,4>}:  Annual  Budgetfry  Pocuments- ^ 
0.4,3;  Contracts  to  Support  SF21 
Program  Office 

0,4.4:  Resource  Allocation  Decisions 

Provides  partial  basis  for  decisions. 


1|2|3|4|5[6|7|8| 


0.4.2;  Contracts  to  Support  Evaluations 

Contracts  required  to  support  evaluations. 


Output  to  Activi 


0.5:  Coordinate  for  Decisions 


0.5:  Coordinate  for  Decisions 
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0.5:  Coordinate  for  Decisions 


Description:  Coordination  and  documentation  of  FAA  position  as  an  input  to  key  program  decisions. 

The  Coordinate  for  Decisions  Task  will  consider  all  of  the  Checklist  activities  as  appropriate.  In  particular, 
the  Administration  of  SF21  Program  Task  will  consider  the  other  management  tasks  (0.1,  through  0.4)  as 
appropriate.  For  simplicity  of  presentation,  the  other  management  tasks  are  NOT  shown  in  the  following 
interaction  tables. 

Plan  and  Perform:  SF2]  Program  Office  POC  =  SF2 1  Progam  Lead 

Approve  or  Accept:  FAA  Lines  of  Business  POC  =  Various 

Products: 

0.5.1:  FAA  Coord,  for  Decision  3.2:  Internal  FAA  coordination  on  the  selection  and  periodic  prioritization 
ofSF2l  Applications. 

0.5.2:  FAA  Coord,  for  Decision  3.3:  Internal  FAA  coordination  on  the  Decision  on  whether  Application 
maturity  is  sufficient  to  justify  limited  evaluation. 

0.5.3:  FAA  Coord,  for  Decision  3.5:  Internal  FAA  coordination  on  whether  an  Application  is  sufficiently 
mature  to  justify  full  evaluation. 

0.5.4:  FAA  Coord,  for  Decision  3.6:  Internal  FAA  coordination  for  Mission  Need  Decision,  a.k.a.  JRC  1. 

0.5.5:  FAA  Coord,  for  Decision  3.7:  Internal  FAA  coordination:  Have  all  significant  issues  been  resolved? 

0.5.6:  FAA  Coord,  for  Decision  3.8:  Internal  FAA  eoordination  for  Initial  Investment  Decision,  a.k.a. 

JRC2a. 

0.5.7:  FAA  Coord,  for  Decision  3.10: 

0.5.8:  FAA  Coord,  for  Decision  3.11: 

0.5.9:  FAA  Coord,  for  Decision  3.12: 

0.5.10:  FAA  Coord,  for  Decision  3.13: 

Issues: 

-  With  the  many  FAA  offices  involved  in  this  program  with  distinctly  different  responsibilities  and  concerns, 
there  is  a  risk  of  conflict  between  FAA  viewpoints  on  a  given  issue;  thus,  developing  an  FAA  position  on  a  key 
program  deeision  may  require  a  decision  at  the  associate  administrator  level 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

3 

3 

3 

3 

3 

3 

3 

3 

LoE  (sm) 

40 


Safe  Flight  21  Generic  Application  Checklist  -  September  28,  2001 


Dependencies  and  Phases: 


De\ 
Con 


Innut  from  Activity: 


0.1:  Develop  and  Revise  SF21  MP 
0.2:  Develop  and  Revise  Checklist 
0.4:  Administer  SF21  Program 

Provides  partial  basis  for  decisions: 


0.3:  Manage  Issues  and  Risks 


' ' '  i.;  '  i,  'V  ''  ' 


Provides  partial  basis  for  decisiorts.  ,  ;  :  : :  " ,  ::  i  i:  ; 


0,4:  Administer  SF21  Program 


Contracts  required  to  support  evaluations. 


0.6:  Develop  Acquisition  Program  Plans 
0,7:  Prepare  Acquisition  Contract 

_ 

Provides  inputs  to  FAA  decision  making.  : 


1.2:  Develop  Detailed  Ops  Concepts  _ J 

1.3:  Develop  Detailed  Systems  Concepts  J]2 

6.1:  Estimate  Performance 

8.5:  Track  Safety  Issues  During  Dev’t 


Prp^idesmputs  ‘  ^  „ 


1.7:  Establish  Mission  Need 


Development  of  the  MNS  will  impact  coordination  for  certain  FAA 


1.8:  Develop  Requirements  Document 
2.5:  Conduct  Investment  Analysis 


Provides  inputs  to  FAA  decision  making. 


2.2:  Analyze  Costs 
2.3:  Analyze  Benefits 


Provides  inputs  to  FAA  decision  makings 


8.6:  Ensure  Safety  of  Testing 
10.3:  Conduct  Joint  Evaluation 


Provides  inputs  to  FAA  decision  making: 


8.7:  Assess  Comparative  Safety 


Innut  via  Product: 


0.1.1:  Safe  Flight  21  Master  Plan 
0.2.1:  Checklist 

0.4.1:  Annual  Budgetary  Documents 
0.4.3:  Contracts  to  Support  SF21 
Program  Office 

0.4.4:  Resource  Allocation  Decisions 


0.3.1:  Risk  Management  Plan 
0.3.2:  Issues  and  Resolutions  Document 
0.3,3:  Risk  Analysis  Reports 
0.3.4:  Risk  Mitigation 


0.4.2:  Contracts  to  Support  Evaluations 


_  0.6.1:  Acquisition  Strategy  Paper 
^  0.6.2:  Program  WBS 

0.6.3:  Integrated  Program  Plan 
0.7.1:  Contract  Package 
0.7.2:  SIR/RFO 


1.2,1:  Detailed  OPS  Concepts 
1.3.1:  Detailed  Systems  Concepts 
L:  6.1.1:  Performance  Expectations 
8.5.1:  Safety  Issues  and  Resolutions 


1.7.1:  Mission  Need  Statement 


_  1.8.2:  Final  Requirements  Document 
2.5.1:  Investment  Analysis  Report 
2.5.2:  Acquisition  Program  Baseline 
(APB) 


3  5 


2.2.1:  Cost  Estimates 
2.3.1:  Benefits  Estimates 


8.6.2:  Test  Safety  Review 
10.3.2:  Joint  Evaluation  Report 


8.7.1:  Comparative  Safety  Analysis 


Provide  guidance  to  FAA  lines  of  business  (including  regulatory  authorities)  on  relative  safety,  and  on  residual 
issues  that  should  be  monitored  to  ensure  safety  benefits. 
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8.11:  Analyze  Hazards  Over-All 

8.12:  Analyze  Hazards  of  Ops  & 

Support 

8.13:  Assess  Health  Hazards 

12.13:  Field  Test  Ground  Systems 

n 

n 

8 

8.11.1:  System  Hazard  Analysis  (SHA) 
8.12.1:  Operating  &  Support  Hazard 
Analysis  (O&SHA) 

8.13.1:  Health  Hazard  Analysis  (HHA) 
12.13.1;  Test  Reports 

m 

■ 

m 

m 

m 

mm 

HH 

Provides  inputs  to  FAA  decision  making. 

,!<  ...  ...  .  ...  . .....  .  1  .. 

No  interact  dependencies  defined 


Output  via  Product: 


0.5.1:  FAA  Coord,  for  Decision  3.2 


Output  to  Activity: 


3.2:  Decision  -  Select  &  Prioritize  Apps 


Coordination  provided  on  the  selection  and  periodic  prioritization  of  SF21  Applications,  r 


0.5.2:  FAA  Coord,  for  Decision  3.3 


p 

[2l 

□ 

□ 

E 

H 

3.3:  Decision  -  Go  for  Limited 

_ 

_ 

_ 

L 

1  1  Evaluation 

Coordination  provided  on  whether  the  Application  is  sufficiently  mature  to  justify  limited  evaluation. 


0.5.3:  FAA  Coord,  for  Decision  3.5; 


a 


1 3.5:  Decision  -  Go  for  Full  Evaluation 


Coordination  provided  on  whether  the  Application  is  sufficiently  mature  to  justify  full  evaluation.  . 


0.5.4;  FAA  Coord,  fo^  Decisiott  3.8 


3.6:  Decision  -  Mission  Need 


0.5.5:  FAA  Coord,  foir  Decisiott 


o 


1 3.7:  Decision  -  Was  OpEval  Adequate? 


0.5.8;  FAA  CooW:  foi-  Detlsiott  3.8 


13.8:  Decision  -  Initial  Investment 


m 

4^3.10:  Decision  -  Sel.  Vendor  &  Award 

□ 

1 

7 

1  Contract 

0.5^84  ::fe£ffiS^rd|il|(r;  DetisittdSiillgi^ 

■ 

m 

II 

■■ 

■ 

■ 

11*  T^£k/'icirkn  ITinckI  Tn't/tf^cftriPtif' 

□ 

j 

_ 

_ 

in 

_ 

IXCCllalUIl  "  AUVcanilCiii 

iC ? •  - ' '  i i ip h : V Ppp!  ipl '  P P  iP'j ^ : .!!  I .  IP  Pp  i"  r  1 ■  i ; '-Pi ■ 

■ 

■ 

HI 

■ 

^8 

■ 

2|3.12:  Decision  -  Formal  FAA/Union 

□ 

□ 

□ 

□ 

□ 

□ 

|7|  1 

E  Agreement 

0.5.t8i»iAili^oo^liSlrlNtiii®^ 

81 

■■ 

■19 
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Overview  of  Activity  0.6:  Develop  Acquisition  Program  Plans 

Description:  Based  on  the  outcome  of  the  investment  analysis  and  the  initial  investment  decision,  develop  the 
plans  necessary  to  acquire  and  implement  the  ground  systems  that  support  the  application(s).  This  can  range 
from  the  development  of  new  systems  to  modifications  of  existing  system  hardware  and/or  software. 

Plan  and  Perform:  Product  Team  POC  =  PT  Lead 

Approve  or  Accept:  IMT  POC  =  IMT  Lead 

Products: 

0.6.1:  Acquisition  Strategy  Paper:  The  Acquisition  Strategy  Paper  defines  the  business  and  technical 
approach  the  Integrated  Product  Team  will  use  to  implement  the  acquisition  program  within  constraints  of  the 
Acquisition  Program  Baseline. 

0.6.2:  Program  WBS:  The  Program  Work  Breakdown  Structure  displays  and  defines  the  product  to  be 
developed  and  every  related  element  of  work  that  must  be  accomplished.  In  addition  to  the  critical  building 
blocks  of  the  system,  the  program  WBS  includes  such  top-level  work  categories  as  program  management, 
training  and  training  equipment,  support  and  support  infrastructure,  facilities,  physical  infrastructure,  test  and 
evaluation,  data  and  data  management,  systems  engineering,  and  deployment.  The  purpose  of  the  program 
WBS  is  to  identify  all  work  that  will  have  to  be  completed  for  the  program  to  be  successful. 

0.6.3:  Integrated  Program  Plan:  The  Integrated  Program  Plan  is  the  single  document  within  the  Acquisition 
Management  System  for  planning  the  detailed  actions  and  activities  the  Integrated  Product  Team  will 
accomplish  to  execute  the  program  within  the  cost  schedule,  benefits,  and  performance  baselines  in  the 
approved  Acquisition  Program  Baseline. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Dur(wk) 

6 

LoE  (sm) 
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Dependencies  and  Phases: 


1.8:  Develop  Requirements  Document 
2.5:  Conduct  Investment  Analysis 

n" 

6 

1  j 

1.8.2:  Final  Requirements  Document 
2.5.1:  Investment  Analysis  Report 

2.5.2:  Acquisition  Program  Baseline 
(APB) 

■ 

■■ 

m 

m 

mmm 

1 

The  FRD  is  used  to  establish  baseline  requirements.  M  Re^rts  are  used-as  inpiU  to  th^  development^ program 

3.8:  Decision  -  Initial  Investment 

J 

71 

3.8.1:  Initial  Investment  Decision 

■ 

ipilBi 

m 

■ 

n 

HHl 

bit 

The  Initial  Investment  Decision  initiates  the-dervelofm^fpf^pr^m^^^ 

Interact  with  Activity: 
0.3:  Manage  Issues  and  Risks 
0.4:  Administer  SF21  Program 
6.3:  Develop  Ground  System  Specs 


0.6.1:  Acquisition  Strategy  Paper  i 

0.6,2^611^^8^ 

0.6,3:  Integrated  l^rbgratti  Plan 


0.5:  Coordinate  for  Decisions 
0.7:  Prepare  Acquisition  Contract 
3.10:  Decision  -  Sel.  Vendor  &  Award 
Contract 

3.11:  Decision  -  Final  Investment 


Provides  inputs  to  ¥aA  decision  maki^^^  for  development  of  contract  Forms  part  of  criteria  for  vendor 

selection.  Progam  planning  documents  used  m  guidance  iH  making  final  investment  decision.  ‘  ' 
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Overview  of  Activity  0.7:  Prepare  Acquisition  Contract 

Description:  Prepare  the  contract  package  and  screening  request/request  for  offer  that  will  be  used  to  select  a 
vendor  and  award  a  contract.  The  contract  package  typically  include  a  Statement  of  Work  (SOW),  Contract 
Data  Requirements  List  (CDRL),  Data  Item  Descriptions  (DIDs),  instructions,  conditions  and  notices  to 
Offerors,  and  evaluation  criteria.  The  Product  Team  will  develop  a  Screening  Information  Request  (SIR)  or  a 
Request  for  Offer  (RFO),  including  the  contract  package  as  the  means  to  solicit  offers  from  prospective 
vendors  and  identify  the  vendor  with  the  best  value. 

Plan  and  Perform:  Product  Team  POC  =  PT  Lead 

Approve  or  Accept:  Product  Team  POC  =  CO 

Products: 

0.7.1:  Contract  Package:  The  contract  package  contains  a  Statement  of  Work  (SOW),  Contract  Data 
Requirements  List  (CDRL),  Data  Item  Descriptions  (DIDs),  and  instructions,  conditions  and  notices  to 
offerors,  and  evaluation  criteria.  The  SOW  contains  specific  contractor  tasking  related  to  procurement  of 
software  and  hardware.  The  CDRL  is  the  primary  vehicle  for  acquiring  documentation  from  the  contractor.  It 
lists  all  deliverable  data  items,  provides  a  delivery  schedule,  and  refers  to  applicable  DIDs.  DIDs  provide 
preparation  instructions  and  formats  for  data  items.  Instructions,  conditions,  and  notices  to  offerors  typically 
contain  provisions  and  information  that  guide  offerors  in  preparing  proposals  or  quotations.  The  items  in  the 
contract  package  should  be  tailored  to  the  requirements  of  the  specific  acquisition. 

0.7.2:  SIR/RFO:  A  Screening  Information  Request  is  a  request  for  documentation,  information, 
presentations,  proposals,  or  binding  offers  by  which  the  Product  Team  identifies  the  offeror  that  provides  best 
value.  A  Request  for  Offer  should  be  used  when  the  selection  decision  will  be  made  after  one  SIR.  The  RFO 
requests  offerors  to  commit  formally  to  provide  products  or  services  under  stated  terms  and  conditions. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

6 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  • 
Full-. 
Lim  -| 

Dev  -| 

Con  —1 


Step 
r  Imp 
r-Tra 


Input  from  Activity: 


0.6:  Develop  Acquisition  Program  Plans  J  :' ' 
6.3:  Develop  Ground  System  Specs 


Required for  development  of  contract 


I  Input  via  Product: 


0.6.1:  Acquisition  Strategy  Paper 
0.6.2:  Program  WBS 
0.6.3:  Integrated  Program  Plan 
6.3.1:  Ground  System  Design 
Specification 

6.3.2:  Interface  Documents 


1  7i  0.5:  Coordinate  for  Decisions 

0.7.1:  Contract  Package  : 

1  7  1 3.10:  Decision  -  Sel.  Vendor  &  Award 

0.7.2:  Sm/RFO, 

Contract 

3.11:  Decision  -  Final  Investment 

Provides  inputs  to  FAA  decision  making.  Forinis  pari  of  criter^iafor  vendor  selection.  Progam  planning  , 

documents  used  a!s  ^idcmceih  making  final  tnvesthierii  decision.  ■  Vj,  j  .  v. «  i'  -  .  ,, 

0.7ilC:;C]6ntiraSi^:.Khcl^ 

|  9-3*  Manufacture  Gnd  Systems  for  Impl. 

o.|.2|;|Mif^M 

1 7  7  9.4:  Deliver  and  Integrate  Gnd  Systems 
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Overview  of  Activity  1.1:  Define  High-Level  Concept 

Description:  Define  a  high-level  concept  that  will  provide  the  framework  for  more  detailed  operational  and 
system  concepts  and  future  development  of  the  application.  This  high-level  concept  also  provides  the  initial 
baseline  against  which  initial  studies  for  the  application  are  planned  and  performed. 

This  activity  is  conducted  in  the  Concept  phase  with  products  updated  as  needed  in  later  phases. 

Plan  and  Perform:  SF21  StG  -  Ops/Proc  SubGroup  POC  =  SF21  StG/OPsG  Co-chairs 

Approve  or  Accept:  SF21  Steering  Group  POC  =  SF21  StG  Co-chairs 

Products: 

1.1.1:  High-Level  Concept:  This  document  provides  a  brief  conceptual  overview  (about  2-3  pages)  of  the 
application,  and  summarizes  high-level  operational  and  system  Implications.  The  document  serves  as  the 
framework  upon  which  more  detailed  operational  and  system  concepts  and  future  development  of  the 
application  are  based,  and  against  which  initial  studies  for  the  application  are  planned  and  performed. 

Issues: 


-  None  (task  completed) 

Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


Decmon(s)  will  impact  the  contents  of  the  documeni(s), , 


Tra 


Input  from  Activitv: 

■  MM’ 

TB 

3.1:  Decision  -  Select  Enhancements 

!!■ 

L_ 

_ 

L. 

_L. 

_ 

_ 

!■ 

m 

■ 

■ 

■ 

mm 

■ 

■1 

Input  via  Product: 


3.1.1:  Roadmap  for  Free  Flight 
Operational  Enhancements 


Interact  with  Activity: 


0.1:  Develop  and  Revise  SF21  MP 
0.2:  Develop  and  Revise  Checklist 
0.3:  Manage  Issues  and  Risks 
0.4:  Administer  SF21  Program 
1.6:  Develop  Research  Evaluation  Plan 


^ . 

i 


versa. 


'  '"'I 


Output  via  Product: 


LI  A:  High-Level  Concept 


Output  to  Activity: 


1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 
1.4:  Identify  Synergistic  Applications 
Sets 


High-level  concept  pi-ovides  basis  for  development  and  revisions  of  detailed  concepts.  High-level  concepts 


P 

P 

T 

1 

P 

□ 

1.1.1:  High-Level  Concept 


■11^ 


E 


1.7:  Establish  Mission  Need 


2.1:  Plan  Cost/Benefit  Analyses 

4.1:  Plan  Procedure  Development 

4.2:  Specify  Procedures 

5.1:  Plan  Human  Factors  Activities 

5.2:  Analyze  Cockpit  Tasks 

5.5:  Analyze  Controller  Tasks 

6.1:  Estimate  Performance 

7.1:  Analyze  Interoperability 

7.2:  Define  Ground  System  Interop. 

8.1:  Plan  Coord.  Safety  Activities 
8.2:  Summarize  Op.  Services  and  Env’t 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 
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Overview  of  Activity  1.2i  Develop  Detailed  Ops  Concepts 

Description:  Expand  the  high-level  concepts  based  on  development  and  evaluation  results  in  the  OCG  to  provide 
detailed  operational  concepts  for  the  application.  The  concepts  should  provide  sufficient  detail  to  identify 
needed  activities  and  involvement  of  LOBs,  identify  and  characterize  the  systems  and  functionality  required 
to  support  the  application,  and  propose  an  initial  functional  decomposition  that  assigns  functions  to  systems. 

Plan  and  Perform:  SF21  StG  -  Ops/Proc  SubGroup  POC  =  SF21  StG/OPsG  Co-chairs 

Approve  or  Accept:  SF21  Steering  Group  POC  =  SF2 1  StG  Co-chairs 

Products: 

1.2.1:  Detailed  OPS  Concepts:  This  document  provides  a  detailed  description  of  the  application  operational 
concept  (about  10  pages),  and  is  based  on  the  high-level  concept.  The  document  serves  as  the  basis  for 
subsequent  cost/benefit,  human  factors,  and  other  analyses,  and  for  joint  evaluations  of  the  application. 

Issues: 

-  Failure  to  obtain  consensus  with  pilot  or  controller  union  representatives  in  the  OPSG,  and  subsequent 
concurrence  by  their  respective  parent  national  union  organizations 

-  Failure  to  complete  the  document  in  a  timely  fashion  to  support  subsequent  assessment  activities 
(cost/benefit,  safety,  joint  evaluations) 

-  Determine  the  need  for  equipage  indication  on  ATC  displays 

-  Determine  the  method  to  be  used  to  maintain  spacing  (range  rings,  other  methods) 

-  Clarify  (potential)  changes  in  roles  or  responsibilities 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

16 

8 

LoE  (sm) 

49 


Safe  Flight  21  Generic  Application  Checklist  -  September  28,  2001 


Dependencies  and  Phases: 


Post  — .  lA 


Dei 

Con 


Input  from  Activity: 


1.1:  Define  High-Level  Concept 


Input  via  Product; 


1.1.1:  High-Level  Concept 


High-level  concept  provides  basis  for  development  and  revisions  of  detailed  concepts. 


_ 4.2.1:  Procedures  Specification 

yf c  u  A  _ Lfr....msM . . 5.2.1:  Cockpit  Task  Analysis  Report 

4.2:  Specify  Proc«l«res  ,  ^  j  5  5  ,.  Task  Analysis  Report 

5.2:  Ana  yre  Cockpit  Ta^  8.2.1:  Operational  Services  and  Env't 

5.5:  Analyze  Controller  Tasks  :  T  i  Definition 

8.2:  Summarise  Op.  Services  and  Env't  -  M;Sg| Jsts:  8.3.1:  Operational  Hazard  Assessment 
8.3:  Perform  Safety  Analyses  ^  3  JSwSfS  :  f;  8.3.2:  Hazard  Analysis  (PHA  or 

8.4:  Allocate  Safety  Objs  &  Reqs  SSHA/SHA) 

SiiWIlBlli  8-4.1:  ASOR 

Procedures  provide  in]f)ut  to  t^^  and  revisions  of  detailed  concepts,. Task  analyses  provide  input  to  the 

definition  and  revisions  of  detailed  c6ncepis:Safe^  Considerations  and  the  heed  for  safety-relevant  specifics 
influence  the  specification  of  the  applications  hoikcepi,  both  for  systems  and  operations,  V. '  /  ^ 


I  1 10.3.1:  Joint  Evaluation  Data 
10.3.2:  Joint  Evaluation  Report 


Results  from  evaluation  are  captured  in  updates  to  concept  “ 


10.3:  Conduct  Joint  Evaluation 


Interact  with  Activi 


0.1:  Develop  and  Revise  SF21  MP  I  12  [31  [51  I  I  I  I  I v;ib‘ , ..  „ 
0.2:  Develop  and  Revise  Checklist  12111  ~T~ ''' 

1.3:  Develop  Detailed  Systems  Concepts  ■'  ',V,  f 

1.4:  Identify  Synergistic  Applications  .  ^  ,  '  .  ’ 3^^'' ^ 

6.1:  Estimate  Performance _ .c.i''' V  .i, 

Provides  insight  into  refinement  of  interacting  activi^  products  ditd  vheMPs^^^e^tsfo'^ib  detailed  concepts 
provides  insight inid Refinements  of performMce  estimates, 'arid.viccyehsa/j  ■■  .  '  y-'j 


Output  via  Product: 


Output  to  Activi 


1.2.1;  Dtolled  OPS  Coileepts  ,..43:'  I  I'j . I . 11..!:  Analyze  Benefits 

Provides  inputsio  FAA  decision  mdkihg:  Ops  concept  provides  inputs  to  benefits  analyses. ^ 


1.5:  Perform  Link  Assessment 


1.2.L  p^alled  dl^S  Concepts  ' 

■'  -  - . . 


1.2.1:  Detailed 'bPS.ediicIpts  ‘2. 3 

llj  »  S  !  S  ^  1  '  (  (  (  «  >t  <  ^1 1  f  1 '»  ‘  I  [  J  I  _ _ _ 

Detailiii  Concepts  provide  inpidiiol^k^a^  of  mission  need,^ 


1 1.7:  Establish  Mission  Need 


-  .4.  ^  **  ,  ^  A  .  \  \  \  I  m  i  t  I  I  1 1.8:  Develop  Requirements  Document 

Concep  " r  » ^ .  I  JJJ__P51J.J_|J2.5:  Conduct  Investment  Analysis 

Detailed  edneepis  provide  jrdmeworkfor  development  qfrequirementi^documents,!Detailedcpnc^tSfp^^id^ 
'wMieVt'or^ jfer  mve5/iweMr<ijralMse.S'' 3' ■ "  W?' : 
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Overview  of  Activity  1.3:  Develop  Detailed  Systems  Concepts 

Description:  Expand  the  high-level  concepts  based  on  development  and  evaluation  results  in  the  OCG  and  other 
forums  to  provide  detailed  systems  concepts  for  the  application.  The  concepts  should  provide  sufficient  detail 
to  identify  needed  activities  and  involvement  of  LOBs,  identify  and  characterize  the  systems  and  functionality 
required  to  support  the  application,  and  propose  an  initial  functional  decomposition  that  assigns  functions  to 
systems. 

Plan  and  Perform:  SC-186  POC  =  SC- 186  Co-chairs 

Approve  or  Accept:  SF21  Steering  Group  POC  -  SF21  StG  Co-chairs 

Products: 

1.3.1:  Detailed  Systems  Concepts:  This  document  provides  a  detailed  description  of  the  application 
operational  concept  (about  10  pages),  and  is  based  on  the  high-level  concept.  The  document  serves  as  the 
basis  for  subsequent  cost/benefit,  human  factors,  and  other  analyses,  for  joint  evaluations  of  the  application, 
and  for  subsequent  standards  development  and  certification  guidance. 

Issues: 

-  Failure  to  complete  the  activity  in  a  timely  fashion  to  support  subsequent  assessment  activities 
(cost/benefit,  safety,  joint  evaluations) 

-  Clarify  (potential)  new  or  modified  air  and  ground  systems  functionality 

-  Propose  allocations  of  functions  to  systems 

-  Determine  anticipated  system  certification  levels  required  for  the  application 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

12 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  -  -  lA 


De^ 

Con 


Innut  from  Activity: 


Input  via  Product: 


1.1.1:  High-Level  Concept 


1.1:  Define  High-Level  Concept 


High^evel  concept  provides  basis  for  development  md  revisions  of  detailed  concepts,  ' 


5.3.1:  Cockpit  Interface  Design 

5  3-  Design  Cockoit  Interface  I  . ^ . ^ . ' . Controller  Interface  Design 

5.3.  Design  cockpit  interlace  ^  2.1 ;  Operational  Services  and  Env't 

5.6:  Design  Controller  Interface  ^  ^ 

8.2:  Summarize  Op.  ^rvices  and  Envt  ,  ■  ,  8J.1:  Operational  Hazard  Assessment 

8.3:  Perform  Safety  Analysts  '  83.2;  Hazard  Analysis  (PHA  or 

8.4:  Allocate  Safety  Objs  «&  Reqs  SSHA/SHA) 

('ilSIiBiiiBIIII  8.4.1:  ASOR 

Cockpit  interface  requirements  provide  input  to  thf  defimfion  and  revisions  of  detailed  concepts.  Jesuits  ofr  , 
controller  interface  design  used  as  input  to  detail^ system  cmceptf  Safety  considerations  and  the  neidfqrf 
sqfety-relevqnt  specifics  will  influence  the  specification  of  the  apflicqtioj^  concept,  boiHfon^  v , ' 


operations. 


7.3:  Validate  Interoperability 
10.3:  Conduct  Joint  Evaluation 


7.3.1:  Interoperability  Validation 
Report 

10.3.1:  Joint  Evaluation  Data 
10.3.2:  Joint  Evaluation  Report 


Assessments  of  interoperability  provide  input  to  the  revisions  of  detailed  systems  concepts,  JlesultsJrom, 
evaluation  are  captured  in  updates  io  concept  documents.  '  , 


Interact  with  Activit 


0.1 :  Develop  and  Revise  SF21  MP  —  ^  a  jia..  I. . i  ""I . I . - 

0.2:  Develop  and  Revise  Checklist 
1.2:  Develop  Detailed  Ops  Concepts 
1.4:  Identify  Synergistic  Applications 

6.1:  Estimate  Performance 

Provides  insight  into  refinementof  interacting  aciiyip  products  dpfi  vice  versa;  Develdfi^epf  of  detailed 
concepts  providesHnsight  into  refinements  offollow-on  products.  '  ■  .. 


s  . 

i'  ■■  £;.’z;k£  ;!liy  yii:  id 


Output  via  Product: 


Output  to  Activi 


UliPefalled  Sysmrns  CncepU  ;  |  1^^  WW-\ . HS  rar;;"?^! 

Provides  inputs  to  FAA  decision  making.  Detailed  concepts  provide  inputs  to  cost/benefit  analyses. 


]s34:  ipetailed  Systenis  Concepts  ££  £  H  - — — — - 1.5:  Perform  Link  Assessment 

Jnitial  concepts  help  define  what  requirements  the  data  link  must  support.  :  ~ _ •  ~  ■£: 


1.3,1.:  Detailed  Systems  Concepts  ,  y - B  . - - - -  1.7:  Establish  Mission  Need 


Detailed  concepts  provide  inputs  to  development  of  mission  need. 
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1.3.1:  Detailed  Systems  Concepts 

'~W 

E 

r: 

1.8:  Develop  Requirements  Document 

. 1 . 1 . 15 

I... 

|2.5:  Conduct  Investment  Analysis 

5.4:  Deflne  Cockpit  Interface  Stds 

6.2:  Define  Performance  Standards 

Detailed  concepts  provide  framework for  development  of  requirements  documents.  Detailed  concepts  provide 
frameworkfor  investment  analyses.  Systems  doncepiSiSupport  standards  development,  f  , 

1.3.1:  Detailed  Systems  Concepts 

B 

¥1 

n 

m 

Bl 

4.2:  Specify  Procedures 

. Jill 

1 

r 

LI 

5.3:  Design  Cockpit  Interface 

5.6:  Design  Controller  Interface 

8.2:  Summarize  Op.  Services  and  Env't 
8.3:  Perform  Safety  Analyses 

8.4:  Allocate  Safety  Objs  &  Reqs 

9.2:  Develop  Ground  Systems  for  Eval. 
10.1:  Plan  Joint  Evaluations 

Provides  guidance  for  conduct  of  activity.  Validates  and  provides  a  reference  for  informal  informatiqnjhprmg in 
previous  phase.  Meiailed  concepts' help  identify-what  ground  systems  are  intended  to  dot.  ^  ^  : 

1.3.1:  Detailed  Systems  Concepts  • 

'  n 

113  fsl 

. 1  1  o.  / .  A.SS0SS  i^oniparaiive  oaieiy 

System  performance  details  provide  background  in  addition  to  (cmd potentially  Revisions  ntqde,  after)  the)OSED. 

1.3.1:  Detailed  Systems  Concepts 

*  ^  ; 

|5  1 

“jo.o.  Jrormaiize  scopes  oi  i^peraiions 

Systeinlslmitdipfused:to''suppori'^qfety'malyses;^^^^^^^^^%^t4^Mf^-^^-v 

1.3.1:  Detailed  Systems  Concepts 

Si 

B 

I 

i 

B 

d9.1:  Develop  Avionics 

2  3  5 

J  11.2:  Plan  and  Apply  for  Avionics  Cert. 

Detailed  concepts  help  identify  M>hdt  avionics  are  intended  to  do.  Systems^  concepts  are  an  input  tpjhe  ,  s 

certification  plan*Wlfir-  ■' 
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Overview  of  Activity  1.4:  Identify  Synergistic  Applications  Sets 

Description:  The  introduction  of  ADS-B  is  unlikely  to  take  place  one  application  at  a  time.  Rather,  both  the 
FAA  and  Industry  expect  that  initial  implementation  for  operational  use  will  involve  a  synergistic  set  of  ADS- 
B  applications.  Subsequent  implementations  may  also  be  in  synergistic  sets.  Identify  those  applications,  in 
conjunction  with  the  development  of  detailed  ops  and  systems  concepts,  that  can  be  grouped  into  synergistic 
sets  so  that  more  realistic  cost/benefit  and  safety  assessments  may  be  performed,  and  so  that  more  efficient 
joint  evaluations  may  be  planned  and  conducted. 

The  Synergistic  Application  Sets  (product  1.4.1)  will  interact  with  or  serve  as  a  major  or  minor  input  to  a 
number  of  other  Checklist  activities.  In  particular,  the  Synergistic  Application  Sets  will  be  an  input  to  the 
various  key  decisions  (3.1  thorough  3.7)  and  the  various  management  tasks  (0.1  through  0.5).  For  simplicity 
of  presentation,  the  key  decisions  and  the  other  management  tasks  are  NOT  shown  in  the  following 
interaction  tables. 

This  activity  is  performed  collectively  for  all  applications. 

Plan  and  Perform:  SF21  StG  -  Ops/Proc  SubGroup  POC  =  SF21  StG/OPsG  Co-chairs 

Approve  or  Accept:  SF21  Steering  Group  POC  =  SF21  StG  Co-chairs 

Products: 

1.4.1:  Synergistic  Application  Sets:  This  product  provides  a  detailed  description  of  the  SF21  applications 
that  would  be  more  attractive  when  implemented  as  a  set.  This  product  will  be  used  as  guidance  for  the 
conduct  of  subsequent  cost/benefit  assessments,  safety  assessments,  and  joint  evaluations.  (This  product  will 
be  developed  collectively  for  multiple  applications.) 

Issues: 

-  Political  considerations  may  favor  the  implementation  of  a  set  of  applications  that  is  less  attractive  than  a 
more  synergistic  set 

-  Identify  the  sets  of  applications  that  will  most  likely  be  used  concurrently  (e.g.,  approach  spacing  and  final 
runway  occupancy  awareness,  approach  spacing  and  enhanced  visual  approaches,  etc.)  to  aid  in  the  assessment  of 
collective  benefits  and  safety 

Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

8 

6 

4 

LoE  (sm) 
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Dependencies  and  Phases: 

F 

Lim 
Dev  -I 
Con 

Input  from  Activity:  HT 

P05 

•ull- 

1 

5t-| 

iii 

11 

-l> 

r 

-s 

tep 
-  Imp 
pTra 

1  p  Ins 

rJHi  Input  via  Product: 

1.1:  Define  High-Level  Concept 

in 

in 

1 

1  1 

1.1.1:  High-Level  Concept 

Hi 

n 

t 

LL 

High-level  concepts  provide  basis  for  initial  definition  bf  synergistic  sets.  .  ‘ 

2.2:  Analyze  Costs 

2.3:  Analyze  Benefits 

2 

m 

u 

2.2.1:  Cost  Estimates 

2.3.1:  Benefits  Estimates 

m 

■::5rn 

_ _ <  V  Vs"’  ' 

Cost  estimates  provide  inputs  to  revisions  to  application  sets.  Benefits  estimates  provide  inputs  to  revisions  to 
applicdtionmsMf-: '  f  ' 

Interact  with  Activity: 


0.1:  Develop  and  Revise  SF21  MP 
0.2:  Develop  and  Revise  Checklist 
1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 


't,  V 


. 

. . . . . . . . . .  ^  ^  I  V,'>  i 

Provides  insight  into  refinement  of  interacting  activity  products  dnd.yic^^a*:M 


»A... 


iiliiiili 

. . Ill 

§th'r 


Ijttifiiiiiaiisl 


Output  via  Product: 

■ 

■ 

H 

3 

PI 

Output  to  Activity: 

1.4.1  {  Synergistic  Application  Sets 

Synergistic  Applications  Sets  provide,  input 

BtBBHn 

2.2:  Analyze  Costs 

2.3:  Analyze  Benefits 

- 

[I 

31  1511  1  M 

to  cost/benefit  analysesm  •  ■. 

1.4.1:  Synergistic  A||>plicatiofi  “ 

■ii 

. :1. _ 

2.4:  Develop  Industry  Business  Cases 

1  1  151  1  1  1  1 

1  Syneirgistic  ApplicMdnsSebfh^cPM^^  to  the  development  of  Industry  business  cases. 

^  1  i4.f :  iljTttilif  iste|i|^ 

Synergistic  Applications  Sets  provide  guida 
development  and  evaluation  prbcejsk  '  ■  ■ 

2a. ■m- ■ 

9.1:  Develop  Avionics 

J3in_5_ii 

ticejd  industry  for  finalizing  avionics  defign  at  various  phases  of  the 

1.4.1  fSylifergistic  ApiJlicatidn  Sete!"  d  1 

Synergistic  Application  Sets  provide :^tdan 
and  evaluation  process.  Syncretic  Afplicc 

2 

B 

9.2:  Develop  Ground  Systems  for  Eval. 
10.1:  Plan  Joint  Evaluations 

L_ 

2_ 

L3  1  1 _ 1_ 

ce  for  finalizing  system  desigps  atpariousphasesofthe  development 
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Overview  of  Activity  1.5:  Perform  Link  Assessment 

Description:  ADS-B  applications  require  the  transmission  of  data.  In  the  design  of  ADS-B  equipment,  the 

choice  of  radio  frequency/spectrum  is  a  significant  issue,  both  nationally  and  internationally.  This  choice  will 
be  based  on  technical,  financial,  and  political  considerations.  Ideally,  it  is  desirable  that  the  same  choice  be 
made  worldwide.  With  this  in  mind,  a  Technical  Data  Link  Assessment  Team  (TLAT)  that  includes 
membership  from  the  FAA  and  Eurocontrol  is  conducting  the  technical  analysis. 

The  Data  Link  Decision  will  interact  with  or  serve  as  a  major  or  minor  input  to  a  number  of  other  Checklist 
activities.  In  particular,  the  Data  Link  Decision  will  be  an  input  to  the  various  management  tasks  (0.1  through 
0.5).  For  simplicity  of  presentation,  interactions  with  .management  tasks  are  NOT  shown  in  the  following 
interaction  tables. 

Plan  and  Perforin:  ASD- 1 00,  With  SF2 1  StG  -  TLAT,  Eurocontrol  POC  =  ASD- 1 00  Rep 

Approve  or  Accept:  AOA-1  POC  =  FAA  Administrator 

Products: 

1.^.1:  Phase  1  Link  Assessment  Report:  This  product,  completed  in  Nov.  1999,  documented  the  results  of 
the  first  phase  of  the  link  analysis.  It  provided  preliminary  conclusions  and  made  recommendations  on  what 
additional  work  was  still  required.  (This  product  was  developed  collectively  for  multiple  applications.) 

1.5.2:  Phase  2  Technical  Link  Assessment  Report:  This  product  will  document  the  results  of  the  work  done 
by  the  Technical  Data  Link  Assessment  Team  (TLAT).  (This  product  is  being  developed  collectively  for 
multiple  applications.) 

Issues: 

-  Within  the  USA,  political  and  financial  considerations  may  not  point  to  a  single  data  link  for  both  general 
aviation  and  air  transport  operations 

-  Throughout  the  world,  various  regulatory  authorities  may  choose  different  data  links 
Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

40 

LoE  (sm) 
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Dependencies  and  Phases: 


Input  from  Activity: 

■  Input  via  Product: 

1.2:  Develop  Detailed  Ops  Concepts 

1.3:  Develop  Detailed  Systems  Concepts 
6.1:  Estimate  Performance 

■ 

L 

m 

■Hi 

j 

1.2.1:  Detailed  OPS  Concepts 

1.3.1:  Detailed  Systems  Concepts 

6.1.1:  Performance  Expectations 

6.1.2:  Estimated  Performance 
Requirements 

■ 

SB 

Initial  concepts  help  define  what  requirements  the  data  link  must  support.  Performance  estimates  guide 
design  and  development  (f  data  link  equipment.  .•  .Ki. 

Interact  with  Activity: 


2.2:  Analyze  Costs 
2.3:  Analyze  Benefits 


_ I  -  .  \  r  4  r. n  ^ y  ‘  .  I  f  . li:  L.hu..;.;  . 

Development  of  cost/benefit  analyses  provides  insight  into  linkassessinents  n  :s^l| 


Output  via  Product: 

3 

Q  n  M 

H  Output  to  Activity: 

i  1.5.1:  Phase  1  Link  Assessment  Report::: 

3.4:  Decision  -  Select  Link(s) 

1.5.2:  Phase  2  Teclthical  Link  . . 
Assessment  Report 

3 

Inputs  to  the  Administrator's  Link  Decision.  .  r  ;  - : 
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Overview  of  Activity  1.6:  Develop  Research  Evaluation  Plan 

Description:  Develop  a  plan  that  identifies  what  the  ADS-B  Integrated  Requirements  Team  (IRT)  considers  to 
be  issues  requiring  resolution  prior  to  development  of  a  Requirements  Document  (RD). 

Plan  and  Perform:  ARR  POC  =  ARR  Rep 

Approve  or  Accept:  ARR  POC  =  ARR  Lead 

Products: 


1.6.1:  Research  Evaluation  Plan: 
Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

24 

LoE  (sm) 
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Dependencies  and  Phases: 


No  input  dependencies  defined 


Interact  with  Activity: 

m  ■  a  mm 

0.1:  Develop  and  Revise  SF21  MP 

0.2:  Develop  and  Revise  Checklist 

0.3:  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program 

1.1:  Define  High-Level  Concept 

Provides  insip^ht  into  refinement  of  interacting  activity  products  and  vice  versa.  ^  -  \ 

Output  via  Product: 


L6,lt  Research  Evaluation  Plan 

The 


1.6.1:  Research  Evaluation  Plan 


X‘’> 


1.6.i:  Rfeseai'ch  Evaluation  Plan 


The  REP  identifies  data  required  to  address  issues  raised.  '-  ^ 


Output  to  Activity: 


1.8:  Develop  Requirements  Document 


_ !,  ■  — ■  ■  • 

J2.1:  Plan  Cost/Benefit  Analyses 
)4.1:  Plan  Procedure  Development 
5.1:  Plan  Human  Factors  Activities 
8.1:  Plan  Coord.  Safety  Activities 
8.2:  Summarize  Op.  Services  and  Env't 
8.3:  Perform  Safety  Analyses 


mmmm 

.  1 

MM 

'*T“ 

T 

T 

1 

_ 

_ 

10.1:  Plan  Joint  Evaluations 
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Overview  of  Activity 
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1.7:  Establish  Mission  Need 


Description:  Develop  a  Mission  Need  Statement  (MNS)  that  documents  the  results  of  mission  analysis,  serves  as 
the  decision  document  for  the  mission  need  decision  and,  after  approval  by  the  JRC,  serves  as  the  basis  for 
investment  analysis.  A  MNS  provides  a  clear,  unambiguous,  and  quantitative  description  of  the  mission  area, 
current  capability,  capability  shortfall  or  technological  opportunity,  required  operational  capability,  impact  of 
disapproval,  benefits,  timeframe,  criticality,  and  LRRAP  resource  estimate. 

Plan  and  Perform:  ARX  POC  =  TBD 

Approve  or  Accept:  ATS  POC  =  TBD 

Products: 

1.7.1:  Mi.ssion  Need  Statement:  The  Mission  Need  Statement  is  the  approval  document  at  the  mission  need 
decision.  It  summarizes  the  decision  factors  relevant  to  a  capability  shortfall  the  agency  should  address  or 
technological  opportunity  for  satisfying  mission  responsibility  more  efficiently  or  effectively.  Approval  by 
the  JRC  authorizes  entry  into  investment  analysis  to  determine  the  best  overall  solution  to  mission  need. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

48 

LoE  (sm) 
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Dependencies  and  Phases: 


_ Input  from  Activity: 

1.1:  Define  High-Level  Concept 


High-level  concepts  provide  basis  for  development  of  mission  need. 


1.2:  Develop  Detailed  Ops  Concepts 

31  1 

!  1 

1.2.1:  Detailed  OPS  Concepts 

1.3:  Develop  Detailed  Systems  Concepts 

HH  ^  ■iHim 

1.3.1:  Detailed  Systems  Concepts 

Detailed  concepts  provide  inputs  to  development  of  mission  need. 


No  interact  dependencies  defined 
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Overview  of  Activity  1.8:  Develop  Requirements  Document 

Description:  Translate  the  mission  need  identified  in  the  Mission  Need  Statement  into  initial  top-level 

operational,  functional,  performance,  and  supportability  requirements.  These  initial  requirements  establish 
the  basis  for  identifying  potential  solutions  to  mission  need,  conducting  market  analyses,  analyzing 
alternatives,  and  assessing  affordability.  Initial  requirements  accommodate  applicable  Congressional 
mandates.  Executive  Orders,  or  Federal  regulations.  They  include  Critical  Operational  Issues  that  must  be 
resolved  by  any  potential  solution.  Initial  requirements  are  evaluated  against  such  factors  as  cost,  benefit, 
schedule,  and  performance  throughout  the  investment  analysis.  They  evolve  to  final  requirements  after 
completion  of  the  analysis. 

Plan  and  Perform:  ARR  POC  =  ARR  Rep 

Approve  or  Accept:  ATS  POC  =  TBD 

Products: 

1.8.1:  Initial  Requirements  Document:  The  initial  Requirements  Document  is  developed  early  in 
Investment  Analysis  by  the  sponsoring  line  of  business.  It  translates  the  "need"  in  the  Mission  Need  Statement 
into  initial  top-level  requirements. 

1.8.2:  Final  Requirements  Document:  The  Final  Requirements  Document  defines  exactly  the  operational 
concept  and  requirements  the  approved  acquisition  program  is  intended  to  achieve.  It  is  the  basis  for 
evaluating  the  readiness  of  resultant  products  and  services  to  become  operational. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-. 

Dev'ri 


Step 
r  Imp 

r-Tra 


Input  from  Activity: 


1.2:  Develop  Detailed  Ops  Concepts 

1.3:  Develop  Detailed  Systems  Concepts 

2.3:  Analyze  Benefits 

6.1:  Estimate  Performance 

8.5:  Track  Safety  Issues  During  Dev't 

8.7:  Assess  Comparative  Safety 

8.8:  Formalize  Scopes  of  Operations 


llltKSiJ 


I _  Input  via  Product: _ 


1.2.1:  Detailed  OPS  Concepts 
1.3.1:  Detailed  Systems  Concepts 
2.3.1:  Benefits  Estimates 
6.1.2:  Estimated  Performance 
Requirements 

8.5.1:  Safety  Issues  and  Resolutions 
8.7.1:  Comparative  Safety  Analysis 
8.8.1:  AC  on  ADS-B/CDTI  Capability 
Levels  and  Lims 


-SgiiSiiiiiilliiiiiiB  Levels  and  Lims 

Detailed  concepts  provide  jrame\vorkfor,developfnent  oj  te0dremeMs  documents.  Benefits  estimates  provide  , 

development  of  requirements.  Results  i^activitiefpid:in^Me!3evel6pMe0jqfrp^Sifemm^^^^^  results 

are  used  as  inputs  to  the  development  dftiqUirements  docurh^htsfAt^pWvtSe^'ihpiiiio  developme$i  cf$; .  ; 

requirements  and  standards.  •  .  ,  . 


1.6:  Develop  Research  Evaluation  Plan 


1.6.1:  Research  Evaluation  Plan 


The  REP  provides  the  framework  for  identifying  requirements. 


_ 1.7.1:  Mission  Need  Statement 

Ib  3.6.1:  Mission  Need  Decision 
.  4.2.1:  Procedures  Specification 

5.5.1:  Controller  Task  Analysis  Report 
£  5.6.1:  Controller  Interface  Design 
;  8.2.1:  Operational  Services  and  Env't 
5'  Definition 

8.3.1:  Operational  Hazard  Assessment 
■  8.3.2:  Hazard  Analysis  (PHA  or 

SSHA/SHA) 

8.4.1:  ASOR 

_ Joint  Evaluation  Report 

The  definition  of  Mission  Need  initiates  investment  c^dlysis-p^dcissis.  Results  of  activities  aidjn  the  ^ 

development  of  requirements  docurnentiRehltsofcm  used  as  input  Id  defining J  ;:'f  “ 


3.7:  Decision  -  Was  OpEval  Adequate? - i.l.l:  OpEval  Adequacy  Decision 

TheOpEval  adequacy  decision  formalizes  the  readiness  to  proceed  to  investment  analysis. ' 


Interact  with  Activi 


2.5:  Conduct  Investment  Analysis  - .  - - 

The  requirements  in  the  iRD  dre  refined  as  the  investmeht  analyses  continue.  '<  ^  r  '■ ;;  ?  .  siS  ; 


1.7:  Establish  Mission  Need 

3.6:  Decision  -  Mission  Need 

4.2:  Specify  Procedures 

5.5:  Analyze  Controller  Tasks 

5.6:  Design  Controller  Interface 

8.2:  Summarize  Op.  Services  and  Env't 

8.3:  Perform  Safety  Analyses 

8.4:  Allocate  Safety  Objs  &  Reqs 

10.3:  Conduct  Joint  Evaluation 


Output  via  Product: 


1.8.1:  Initial  Requirements  Document 


Output  to  Activi 


2.5:  Conduct  Investment  Analysis 


The  iRT>  establishes  tlie  initicdreqinrenkhts  that  gui^  the  initial  investment  analyses. 
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1.8.2;  Final  Reqnirements  Document^^ 

R 

V- 

:v=.- 

I 

0.5:  Coordinate  for  Decisions 

6 1 6 

.. 

Provides  inputs  to  FAA  decision  makingJ^^^ 

1.8.2;  Final  Requir^mients  Document 

R 

0.6:  Develop  Acquisition  Program  Plans 
3.8:  Decision  -  Initial  Investment 

6.3:  Develop  Ground  System  Specs 

” 

!6 

n 

_ 

The  FED  is  used  to  establish  baseline  requirements 

sTheFRD  isyused  as  input  to  thFJnitidlTnvestmehkP 
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Overview  of  Activity  2.1 1  Plan  Cost/Bcnefit  Analyses 

Description:  Develop  plans  for  operational  analysis,  metrics  definition,  and  data  collection,  and  identify  the  tools 
and  models  necessary  to  analyze  the  application  as  part  of  a  broader  initial  analysis  of  synergistic  application 
sets.  Coordinate  the  plans  with  application  stakeholders. 

The  plan  will  be  updated  as  needed  as  work  progresses.  This  activity  is  performed  collectively  for  all 
applications. 

Plan  and  Perform:  SF21  StG  -  Cost/Benefit  SubGroup  POC  =  SF21  StG/CBsG  Co-chairs 

Approve  or  Accept:  SF21  Steering  Group  POC  =  SF21  StG  Co-chairs 

Products: 

2.1.1:  CBA  Plan:  The  Cost/Benefit  Analysis  (CBA)  Plan  outlines  the  basic  steps  and  activities  that  need  to 
be  carried  out  to  analyze  and  assess  the  costs  and  benefits  for  a  set  of  applications.  The  plan  identifies  the 
scope  of  the  analyses  to  be  conducted,  and  provides  a  high-level  schedule  for  completion.  The  plan  also 
includes  the  metrics  by  which  benefits  will  be  measured  and  analyzed.  The  activities  outlined  in  the  plan  are 
not  part  of  the  FAA  Investment  Analysis  process,  but  may  produce  results  that  can  be  used  as  inputs  to  that 
process  for  those  applications  in  the  set  that  may  require  it. 

Issues: 


-  None  (activity  completed) 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

start  Date 

Dur  (wk) 

12 

LoE  (sm) 
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Dependencies  and  Phases: 


Input  from  Activity: 


1.1:  Define  High-Level  Concept 
1.6:  Develop  Research  Evaluation  Plan 

addressed. 


Input  via  Product; 


1.1.1:  High-Level  Concept 
1.6.1:  Research  Evaluation  Plan 


Vi  The  REP  identifies  issues  that  need  : 


Interact  with  Activity: 

0.1:  Develop  and  Revise  SF21  MP 

11  1  I  j  '"j ' ' 

0.2:  Develop  and  Revise  Checklist 

0.3:  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program 

. . 

’ng  aetivity  praduets  and  vice:  versa.  7 '  • 

Provides  insight  into  refinement  qfimteracti 

Output  via  Product 


The  CEA  plan  provides  guidance  for  cost/beriefit  mafyses- 


_ Output  to  Activity: 

2.2:  Analyze  Costs 
2.3:  Analyze  Benefits 
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2.2:  Analyze  Costs 


Description:  Develop  estimates  of  costs  for  the  application  as  part  of  a  broader  refined  analysis  of  synergistic 
application  sets.  Identify  the  system  constraints  and  parameters  affecting  the  analysis  and  how  these 
constraints  and  parameters  should  be  characterized.  Coordinate  the  analysis  with  application  stakeholders. 

The  cost  estimates  for  the  applications  will  be  used  to  support  industry  business  cases,  and  to  evaluate  cases 
for  implementing  synergistic  application  sets  as  part  of  a  subsequent  FAA  investment  analysis.  The 
constraints  and  parameters  that  need  to  be  characterized  will  be  used  in  planning  application  development  and 
operational  evaluation  activities.  Results  on  critical  parameter  trade-offs  may  be  used  to  plan  subsequent 
refinement  of  the  application.  [This  activity  is  performed  collectively  for  all  applications.] 

Plan  and  Perform:  SF21  StG  -  Cost/Benefit  SubGroup  POC  =  SF21  StG/CBsG  Co-chairs 

Approve  or  Accept:  SF21  Steering  Group  POC  -  SF21  StG  Co-chairs 

Products: 

2.2,1:  Cost  Estimates:  In  accordance  with  the  CBA  Plan,  cost  estimates  provide  an  estimate  of  the  costs  of 
the  system  architecture  and  its  implementation  that  would  be  required  to  support  the  set  of  applications. 
Estimates  are  developed  based  on  detailed  system  concepts  and  updated  as  application  development 
progresses.  All  cost  estimates  are  developed  in  concert  with  benefits  estimates  for  the  same  set  of 
applications.  Cost  estimates  are  used  to  support  the  decision  to  proceed  with  joint  evaluations  and  to  support 
industry  business  cases.  These  estimates  are  not  developed  as  part  of  the  FAA  Investment  Analysis  process, 
but  may  be  used  as  inputs  into  that  process  for  those  applications  in  the  set  that  may  require  it. 

Issues: 

-  The  maturity  of  cost  estimates  may  not  meet  stakeholders’  expectations  for  decision  making  in  the  earlier 
phases  of  application  development  (error  ranges  on  early  estimates  need  to  be  strongly  emphasized) 

-  Methods  for  accounting  for  quantities  of  scale  need  to  be  identified  and  implemented  as  part  of  the  cost 
estimate  process 

-  Assumptions  for  the  analysis  need  to  be  identified  and  industry  consensus  obtained 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

start  Date 

Dur  (wk) 

16 

16 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


Input  from  Activity: 


1.3:  Develop  Detailed  Systems  Concepts 
1.4:  Identify  Synergistic  Applications 
Sets 


Input  via  Product: 


1.3.1:  Detailed  Systems  Concepts 
1.4.1:  Synergistic  Application  Sets 


Detailed  concepts  provide  inputs  to  cost/benefit  analyses,  S^ergistic  Applications  Sets  provide  input  to 
dost/beneflt 


D 

■nn 

■ 

■■ 

■ 

■ 

D 

■ 

■ 

HHI 

1 

2.1:  Plan  Cost/Benefit  Analyses 


2.1.1:  CBAPlan 


Dhe 


3  1 

X  eriorm  /ysscNsiiiuiii 

iHya 

Development  of  cost/benefit  analyses  provides  insighfinto  link  assessments  and  vicWwfsg: 


2.3:  Analyze  Benefits 

— 

Mila 

1 

1 

Cost  analyses proyide  insight  into  benefits ^a^ 

Output  via  Product: 

I 

B 

3 

m 

□ 

H  Output  to  Activity: 

0.5:  Coordinate  for  Decisions 

Provides  inputs  to  FAA  decision  making.^>l 

_ 

|3 

ZLUJ 

J 

2f2«lt,post|;stiniatd 

T 

i" 

1.4:  Identify  Synergistic  Applications 
Sets 

□ 

,2| 

31 

{Cost  estimates  provide  inputs  to  revisions  to  applicaHon  se(s.  - 

2.24  s  Cost  Estimates 

- 

n 

2.4:  Develop  Industry  Business  Cases 

2.5:  Conduct  Investment  Analysis 

□ 

_ 

_ 

MS 

□ 

I 

u 

Costt/benefit  estimates  support  development  ofii^ustry  business^  cases:  Cost/benefit  es:timates  are  used  as  the 
Starting pointfor- investment  analyses^' 
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2.3:  Analyze  Benefits 


Description:  Develop  estimates  of  benefits  for  the  application  as  part  of  a  broader  refined  analysis  of  synergistic 
application  sets.  Identify  the  constraints  and  parameters  affecting  the  analysis  and  how  these  constraints  and 
parameters  should  be  characterized  (through  additional  measurement  and  analysis)  to  more  accurately 
estimate  benefits  as  the  application  is  further  developed  and  evaluated.  Validate  and/or  refine  benefits  models 
and  metrics  based  on  analysis  of  available  evaluation  data.  Coordinate  the  analysis  with  application 
stakeholders. 

The  benefits  estimates  for  the  applications  will  be  used  to  support  industry  business  cases,  and  to  evaluate 
cases  for  implementing  synergistic  application  sets  as  part  of  a  subsequent  FAA  investment  analysis.  The 
constraints  and  parameters  that  need  to  be  characterized  will  be  used  in  planning  application  development  and 
operational  evaluation  activities.  Results  on  critical  parameter  trade-offs  may  be  used  to  plan  subsequent 
refinement  of  the  application. 

Plan  and  Perform:  SF21  StG  -  Cost/Benefit  SubGroup  POC  =  SF21  StG/CBsG  Co-chairs 

Approve  or  Accept:  SF21  Steering  Group  POC  =  SF21  StG  Co-chairs 

Products: 

2.3.1:  Benefits  Estimates:  In  accordance  with  the  CBA  Plan,  benefits  estimates  provide  an  estimate  of  the 
benefits  that  would  be  obtained  by  the  implementation  of  the  set  of  applications.  Estimates  are  developed 
based  on  detailed  operational  concepts  and  updated  as  application  development  progresses.  All  benefits 
estimates  are  developed  in  concert  with  cost  estimates  for  the  same  set  of  applications.  Benefits  estimates  are 
used  to  support  the  decision  to  proceed  with  joint  evaluations  and  to  support  industry  business  cases.  These 
estimates  are  not  developed  as  part  of  the  FAA  Investment  Analysis  process,  but  may  be  used  as  inputs  into 
that  process  for  those  applications  in  the  set  that  may  require  it. 

2.3.2:  Benefits  Data  Collection  Requirements:  Data  collection  requirements  are  defined  for  joint  evaluation 
activities,  so  that  benefits  data  can  be  obtained  to  validate  the  models  used  to  arrive  at  the  estimates. 

Issues: 

-  The  structured  environment  in  which  joint  evaluations  are  conducted  may  not  lend  itself  to  sufficiently 
validating  assumed  benefits  mechanisms 

-  The  maturity  of  benefits  estimates  may  not  meet  stakeholders’  expectations  for  decision  making  in  the 
earlier  phases  of  application  development  (error  ranges  on  early  estimates  need  to  be  strongly  emphasized) 

-  Assumptions  for  the  analysis  need  to  be  identified  and  industry  consensus  obtained 


Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

16 

16 

12 

LoE  (sm) 
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Dependencies  and  Phases: 


Input  from  Activity: 


1.2:  Develop  Detailed  Ops  Concepts 
1.4:  Identify  Synergistic  Applications 
Sets 


Input  via  Product; 


1.2.1:  Detailed  OPS  Concepts 
1.4.1:  Synergistic  Application  Sets 


_ A _ 


Op^  gm'^ptprmi4^s:^p^s  to  benefits 


2.1:  Plan  Cost/Benefit  Analyses 

n 

■■■■■ 

■ 

■■ 

m 

2.1.1:  CBA  Plan 

m 

DIM"  B 

m 

mm 

m 

The  CB A  plan  provides  guidance  for  cost/benefit  analysfst 

m 

10.3:  Conduct  Joint  Evaluation 

■BEnn 

I] 

10.3.1:  Joint  Evaluation  Data 

m 

■ 

m 

■ 

mm 

III 

10.3.2:  Joint  Evaluation  Report 

Evaluation  results  enable  validation  of  benefits  models  and  assumptions.  ■  - 

3 

j 

I 

i.d:  X  eriorin  /vsscssnieni  ~ 

p 

1  - 

[Development  ofcost/beneflt  analyses  provides  insight  into  i 

Unk  assessments  and  vice':versaM<  ■  C, 

2.2:  Analyze  Costs 

:2y.,ki. 

■ 

"1”' 

Cost  analyses  provide  insight  into  benefits  analyses,  and  vice  versa 

Output  via  Product: 


2.3.1:  Benefits  Estimates 


Output  to  Activity: 


0.5:  Coordinate  for  Decisions 


Provides  inputs  to  FAA  decm6nMc0n;^:W::/:' 


iiiifiiiPiilii 

2  H 

g 

-r 

> 

-  1 1.4:  Identify  Synergistic  Applications 

iliiiliE 

121 

U 

_ 1 

_ 

_ i 

_ 1 

JSets 

2.3.}  :  Benefits  Estimates 


Benefits  estimates  provide  inputs  to  revisions  to  appUcqtion  sets. 


2.3.1:  Benefits  Estimates 


1.8:  Develop  Requirements  Document 
2.4:  Develop  Industry  Business  Cases 
2.5:  Conduct  Investment  Analysis 


Benefits  estimates  provide  guidance  in  the  development  of  tfie  iRD.  Cost/benefit  estimates  support  deyelppment 
of  industry  business  cases.  Cost/benefit  estimates  are 


2.3.2:  Benefits  Data  Collection 
Re|uiret^f  s5 
Identifies  benefits  data  to  be  collected  during  evaluations.  ■  ^ 


2  3 


10.1:  Plan  Joint  Evaluations 
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Overview  of  Activity  2.4:  Develop  Industry  Business  Cases 

Description:  This  step  is  assumed  to  be  required  in  order  for  industry  to  make  the  leap  from  refined  cost  and 
benefits  estimates  to  making  an  investment  decision  to  manufacture/equip  with  avionics.  This  step  is  assumed 
to  be  the  industry  equivalent  to  the  FAA’s  Investment  Analysis  activity. 

This  activity  is  performed  collectively  for  application  sets  of  interest  to  industry  stakeholders. 

Plan  and  Perform:  Industry  Stakeholders  POC  =  Various 

Approve  or  Accept:  Industry  Stakeholders  POC  =  Various 

Products: 

2.4>1:  Industry  Business  Cases:  The  business  cases  provide  the  justification  for  industry  stakeholders  to 
equip  with  avionics  (airline)  or  manufacture  avionics  (vendor).  The  business  cases  are  based  primarily  on 
costs  and  benefits  analyses,  and  joint  evaluation  results.  The  business  cases  are  also  used  as  input  to 
applicants’  development  of  certification  and  operational  approval  plans. 

Issues: 


-  The  methods  and  criteria  that  industry  uses  to  develop  business  cases  are  unclear,  which  makes  subsequent 
industry  buy-in  uncertain  (even  after  successful  post-eval  activities)  and  places  implementation  at  risk 

Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  “1  ^  lA 


Input  from  Activity: 


1.4:  Identify  Synergistic  Applications 
Sets 

2.2:  Analyze  Costs 
2.3:  Analyze  Benefits 


Input  via  Product: 


1.4.1:  Synergistic  Application  Sets 
2.2.1:  Cost  Estimates 
2.3.1:  Benefits  Estimates 


Synergistic  Applications  Sets  provide  input  to  thedeyelopmmt  of  Industry  business  cases.  Cpst/benefit  estimates 


■ 

■ 

■ 

■ 

■ 

■I 

H 

m 

m 

m 

mem 

■ 

HI 

3.7:  Decision  -  Was  OpEval  Adequate? 


3.7.1:  OpEval  Adequacy  Decision 


The  OpEval  adequacy  decision  formalizes  the  readiness  to  proceed  to  investment  analysis.  ; 


No  interact  dependencies  defined 


Output  via  Product:  H 

HI 

in 

H  ■  Output  to  Activity: 

2,4, J;  Industry  Business  Cases 

ITS 

■j  1 3.9:  Decision  -  Industry  Commits  to 

i  I  Ilmpl. 

11.2:  Plan  and  Apply  for  Avionics  Cert. 
12.1:  State  Intent  to  Conduct  New  Flight 
Ops  (Ph.  1) 

Industry  business  cases  support  stakeholder  buy-in  to  eguip/manufacture.  Industry  business  eases  provide  basis 
for  applicants  ’  certification  plan.  Industry  business  cases  provide  basis  for  ops  approval  application. 
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Overview  of  Activity  2.5:  Conduct  Investment  Analysis 

Description:  Investment  analysis  generates  the  information  needed  by  the  Joint  Resources  Council  (JRC)  at  the 
investment  decision  to  determine  whether  the  agency  should  invest  resources  to  satisfy  the  mission  need,  and 
if  so,  to  identify  which  candidate  solution  to  select  for  implementation  and  to  determine  whether  that  solution 
is  affordable.  Investment  analysis  is  triggered  by  JRC  approval  of  a  new  Mission  Need  Statement,  an 
anticipated  breach  to  the  cost  baseline  of  an  approved  acquisition  program,  or  the  need  for  an  investment 
decision  on  whether  to  substantially  upgrade  an  existing  capability.  An  investment  analysis  thoroughly 
analyzes  and  assesses  the  affordability  of  candidate  solutions  for  obtaining  the  needed  capability  and 
quantifies  the  cost,  schedule,  performance,  and  benefit  baselines  for  those  solutions.  At  the  same  time,  the 
mission  analysis  group  of  the  sponsoring  line  of  business  revalidates  mission  need  and  determines  its  current 
priority  among  all  agency  needs.  An  Investment  Analysis  Team  is  established  consisting  of  representatives 
from  the  sponsoring  organization,  acquiring  organ ization(s),  the  investment  analysis  staff,  and  other 
organizations  as  needed.  Investment  analysis  activities  culminate  in  an  Investment  Analysis  Report  submitted 
to  the  JRC  by  the  Director,  Investment  Analysis  staff,  and  an  Acquisition  Program  Baseline  for  each 
candidate  solution. 

Plan  and  Perform:  ASD  POC  =  TBD 

Approve  or  Accept:  ASD  POC  =  TBD 

Products: 

2.5.1:  Investment  Analysis  Report:  The  Investment  Analysis  Report  is  the  primary  decision  document  at  the 
investment  decision.  The  intent  of  the  report  is  to  quantify  and  display  the  relative  strengths  and  weakness, 
advantages  and  disadvantages  of  each  candidate  solution  so  the  JRC  can  make  an  informed  selection. 

2.5.2:  Acquisition  Program  Baseline  (APBl:  The  Acquisition  Program  Baseline  defines  the  cost,  schedule, 
benefits,  and  performance  baselines  for  the  acquisition  program.  It  is  the  mutual  agreement  between  the  JRC, 
the  provider  organization,  and  the  user  organization  concerning  the  capability  and  benefits  the  program  will 
provide  and  the  cost  and  schedule  authorized  for  the  program.  The  APB  also  establishes  performance  metrics 
for  assessing  program  success  and  advancing  it  through  the  acquisition  lifecycle. 


Schedule: 
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Full 
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Dependencies  and  Phases: 


Post 
Full-. 
Lim  -| 
Dev  -| 

Con  ^  I 


Step 

pimp 

i-Tra 


Inout  from  Activity:  ■  HIM  M  Hil  M _ Input  via  Product: _ 


1.2:  Develop  Detailed  Ops  Concepts  MM  [5M  I  I  1.2.1:  Detailed  OPS  Concepts 

1.3:  Develop  Detailed  Systems  Concepts  I  L.  I'  i . H  I  \  \  1.3.1:  Detailed  Systems  Concepts 

2.2:  Analyze  Costs  2.2.1:  Cost  Estimates 

2.3;  Analyze  Benefits  2.3.1;  Benefits  Estimates _ 

Detailed  concepts  prpvide  framework  for  inv?s^f^(  amlyseSj^Qast/henefit  estimates  are  t^ed  as  the  starting 

point  for  investment  analyses.  ■  ■"  '''  ,'"‘^,‘^'1^'’!','  _ ^ 

1.7:  Establish  Mission  Need  I  I  111  LJ  I  I  I  Mission  Need  Statement 

3.6:  Decision  -  Mission  Need _ L  I'M  M  i  ■/  jj,,  J  J.„,U  3.6.1:  Mission  Need  Decision _ 


The  definition  of  Mission  Need  initiates  investment  analysis  processes. _ ■  . '  ‘ 

1.8:  Develop  Requirements  Document  |  [  [  I  I  [61  I  I  I  1 1.8.1;  Initial  Requirements  Document 
3.7:  Decision  -  Was  OpEval  Adequate?  I  ■  J LI. P .LlJ^  3.7.1:  OpEval  Adequacy  Decision 

The  iJHD  establishes  the  initied  requirements  tfiaf  g^idtl^Mid^  investment  analyses.  The  OpEval  adequacy 
decision  formalizes  the  readiness  to  proceed  to  investment  analysis.  »  -  , 


Interact  with  Activi 


1.8:  Develop  Requirements  Document  . . . . 

. . . -.yj 

The  requirements  in  the  iRD  are  refined  as  the  investment  analyses  continui^N^.y:''>t- 


Miss" 


Output  via  Product: 


2.5.1:  Investment  Analysis  Report 
2.5.2;  Acquisition  Program  Baseline 


i&l 


Output  to  Activi 


1 0.5:  Coordinate  for  Decisions 


2.5.tt  Tnvestment  Analvsis  Report  ;  I  r  M  0  |  I  I  10.6;  Develop  Acquisition  Program  Plans 

2.54;  Acquisition  Program  Baseline  M  M  I  |6.1.J.„.„L_]  3.8:  Decision  -  Initial  Investment 
(APB):  i;  3.11:  Decision  -  Final  Investment 

li  Reports  are  used  as  input  to  tHe  development  of  program  plans.  U  Reports  are  used  as  injjut  to  tr^  Investment 
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Overview  of  Activity  3.1:  Decision  -  Select  Enhancements 

Description:  Develop  an  FAA/Industry  consensus  on  what  National  Airspace  System  (NAS)  operational 
enhancements  should  be  pursued  by  a  joint  FAA/Industry  program.  [Conceivably  this  decision  could  be 
revisited  to  add  or  subtract  enhancements  to  the  ones  originally  selected.  Flowever,  this  is  not  presently 
anticipated.]  Activities  enabled  by  this  decision  are  shown  as  outputs  in  the  tables  that  follow. 

The  Select  Enhancements  Decision  will  serve  as  a  major  or  minor  input  to  all  of  the  Checklist  activities.  For 
simplicity  of  presentation,  only  the  most  important  interactions  are  shown  in  the  following  tables. 

Plan  and  Perform:  N/A  POC  =  N/A 

Approve  or  Accept:  FAA  and  Industry  Stakeholders  POC  =  Various 

Products: 

3.1,1:  Roadmap  for  Free  Flight  Operational  Enhancements:  This  August  1998  document  defines  the  9 
enhancements  that  are  to  be  achieved  with  the  implementation  of  the  various  SF21  applications. 


Schedule: 
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start  Date 

Dur  (wk) 

0 
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Dependencies  and  Phases: 


No  input  dependencies  defined 


No  interact  dependencies  defined 


Output  via  Product: 


3.1,1:  Hoadmap  for  Free  Flight 
Operational  Fnhaneemeats 


Output  to  Activi 


1 0.1:  Develop  and  Revise  SF21  MP 
lo.2:  Develop  and  Revise  Checklist 
0.3:  Manage  Issues  and  Risks 
0.4:  Administer  SF21  Program 
1.1:  Define  High-Level  Concept 


Roadmap  identifies  things  to  be  addressed  in  thp  original  SF  21  Master  Plan.  Decisionfs)  'will  impact  the 
contents  of  the  document(s).  _ 
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Overview  of  Activity  3.2:  Decision  -  Select  &  Prioritize  Apps 

Description:  Select  SF21  applications  that  will  enable  us  to  achieve  the  enhancements  selected  in  Decision  3.1. 
[FAA  and  Industry  Stakeholders  may  revisit  the  list  of  selected  applications  and  propose  additions  or 
subtractions  from  this  list.]  Establish  priorities  among  the  various  applications  and  among  the  work  efforts 
required  to  pursue  the  implementation  of  these  applications.  [This  is  done  on  a  periodic  basis  (approximately 
annually).]  Activities  enabled  by  this  decision  are  shown  as  outputs  in  the  tables  that  follow. 

The  Select  and  Prioritize  SF21  Applications  Decision  will  serve  as  a  major  or  minor  input  to  virtually  all  of 
the  Checklist  activities.  For  simplicity  of  presentation,  only  the  most  important  interactions  are  shown  in  the 
following  tables. 

Plan  and  Perform:  N/A  POC  =  N/A 

Approve  or  Accept:  FAA  and  Industry  Stakeholders  POC  =  Various 

Products: 

3.2>1:  Application  Target  Schedule:  The  results  of  this  selection  and  prioritization  are  included  in  the 
periodic  revisions  of  the  SF2I  Master  Plan. 


Schedule: 


Con 

Dev 

Ltm 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

start  Date 

Dur  (wk) 

0 

LoE  (sm) 

! 
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Dependencies  and  Phases: 

Post  -I  I-  lA 


Input  from  Activity: 

■ 

IMM* 

»■■■■ 

A 

Input  via  Product: 

0.5:  Coordinate  for  Decisions 

■ 

■ 

■ 

■ 

fl 

B 

B 

B 

0.5.1:  FAA  Coord,  for  Decision  3.2 

I 

■ 

■ 

mm 

HB 

a 

IB 

B 

-mm 

B 

■ 

No  interact  dependencies  defined 


Output  via  Product: 

1 

m 

B  Output  to  Activity: 

3,2.1?  Applicatioii  Target  Schedule 

_n0.1:  Develop  and  Revise  SF21  MP 

T 

_ 

"J  0.2:  Develop  and  Revise  Checklist 

0.3:  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program 

Decision(s)  will  impact  the  contents  of  the  documetit(s): 
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Overview  of  Activity  3.3:  Decision  -  Go  for  Limited  Evaluation 

Description:  Is  this  application  sufficiently  mature  to  justify  its  limited  evaluation  in  the  next  OpEval?  [This 
decision  should  consider  informal  inputs  from  pilot  unions,  controller  unions,  FAA  management,  and  Industry 
management.]  Does  this  Application  show  sufficient  promise  (costs  versus  benefits)  to  justify  simulation  and 
flight  test  evaluation?  Have  the  procedures  to  be  tested  been  developed  to  a  maturity  that  justifies  evaluation? 
Have  the  avionics  to  be  tested  been  developed  to  a  maturity  that  justifies  evaluation?  [This  decision  should 
consider  informal  inputs  from  pilot  unions,  controller  unions,  FAA  management,  and  Industry  management.] 
Activities  enabled  by  this  decision  are  shown  as  outputs  in  the  tables  that  follow. 

The  Go  for  Limited  Evaluation  Decision  will  serve  as  a  major  or  minor  input  to  many  subsequent  Checklist 
activities.  For  simplicity  of  presentation,  only  the  most  important  interactions  are  shown  in  the  following 
tables. 

Plan  and  Perform:  N/A  POC  =  N/A 

Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

3.3.1:  Decision  to  Undertake  Limited  Evaluation:  Many  different  organizations  and  individuals  have  an 
interest  in  influencing  this  decision.  The  OCG  provides  a  forum  where  these  opinions  can  be  voiced  and 
considered. 


Schedule: 
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0 
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Dependencies  and  Phases: 

P 
Ful 
Lim  -n 
Dev  -I 
Con  -|  1 

Innut  from  Activity:  HPl 

1 

■?. 

n 

1  1 

■i 

I 

If 

3 

np 
-  Tra 

P  Ins 

Innut  via  Product: 

0.5:  Coordinate  for  Decisions 

■1 

mmam 

in 

■1 

n 

H 

0.5.2:  FAA  Coord,  for  Decision  3.3 

n 

mi  mm 

■1 

■1 

■i 

!■ 

Coordination  provided  on  whether  the 

'ication  is  sufficiently  mature  to  justify  limited  evaluation. 

No  interact  dependencies  defined 


Output  via  Product: 

■n 

3' 

■ 

yj  Wi 

nn 

H  Output  to  Activity: 

3.3.1;  Decision  to  Undertake  Limited 
Evaluation 

-y 

0.1:  Develop  and  Revise  SF21  MP 

0.2:  Develop  and  Revise  Checklist 

. L3_ 

0.3:  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program 

10.1:  Plan  Joint  Evaluations 

Decishnjs)  will  impact  the  contents  the  document{^t  jpieuisidnjusti/ieMimitedevalitation,  y 
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Overview  of  Activity 


Safe  Flight  21  Generic  Application  Checklist  -  September  28,  2001 

3.4:  Decision  -  Select  Link(s) 


Description:  Based  on  political,  economic,  and  technical  considerations;  the  FAA  Administrator  decides  which 
data  link(s)  the  FAA  will  support  for  the  transmission  of  ADS-B  data. 

Plan  and  Perform:  N/A  POC=N/A 

Approve  or  Accept:  AOA- 1  POC  =  FAA  Administrator 

Products: 

3.4.1:  Link  Decision:  (This  decision  will  be  made  collectively  for  multiple  applications.) 


Schedule: 


Con 

Dev 
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Full 

Post 
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Dur  (wk) 
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Dependencies  and  Phases: 


Post  “n  T-  lA 


Input  from  Activity: 


1.5:  Perform  Link  Assessment 


Inputs  to  the  Administrator  's  Unk  Pecisidm 


Input  via  Product: 


1.5.1:  Phase  1  Link  Assessment  Report 
1.5.2:  Phase  2  Technical  Link 
Assessment  Report 


No  interact  dependencies  defined 


Output  via  Product: 

■~n 

w 

HI 

Output  to  Activity: 

- 

0.1:  Develop  and  Revise  SF21  MP 

3.4.1:  Link  Decision 

|3|  1 

J 

0.2:  Develop  and  Revise  Checklist 

0.3:  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program 

\Decision(s)  will  impact  the  contents  of  the  document(s). 

3.4.1:  tink  Decision 

ici 

6.1:  Estimate  Performance 

M 

3_ 

1  The  Link  Decision  is  required  to  refine  performance  estimates. 

_ ri'i ' ' u::;;;' ' - . '' fe:- ; ' •? ■■■ 

3f4.1::£|nkDec§ipn 

: 

9.1:  Develop  Avionics 

I  113 

1. 

The  Link  Decision  is  required  so  that  Indus 

try 

canfint 

alii 

m 

on 

m 

\di 

?sign  without  the  risk  that  the  FAA  will 

later  choose  not  to  support  the  avionics' data  link' 
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Overview  of  Activity  3.5i  Decision  “  Go  for  Full  Evaluation 

Description:  Is  this  Application  ready  to  be  fully  evaluated  during  an  upcoming  OpEval?  [This  decision  should 
consider  informal  inputs  from  pilot  unions,  controller  unions,  FAA  management,  and  Industry  management.] 
Does  this  Application  show  sufficient  promise  (costs  versus  benefits)  to  justify  simulation  and  flight  test 
evaluation?  Have  the  procedures  to  be  tested  been  developed  to  a  maturity  that  justifies  evaluation?  Are  the 
cockpit  and  controller  task  analyses  and  the  resulting  interface  designs  sufficiently  mature  to  justify 
evaluation?  Have  the  avionics  to  be  tested  been  developed  to  a  maturity  that  justifies  evaluation?  Will  this 
evaluation  be  a  Limited  evaluation  or  a  full  OpEval?  Activities  enabled  by  this  decision  are  shown  as  outputs 
in  the  tables  that  follow. 

The  Go  for  Full  Evaluation  Decision  will  serve  as  a  major  or  minor  input  to  many  subsequent  Checklist 
activities.  For  simplicity  of  presentation,  only  the  most  important  interactions  are  shown  in  the  following 
tables. 

Plan  and  Perform:  N/A  POC  =  N/A 

Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

3.5.1:  Decision  to  Plan  for  Full  Evaluation:  (This  decision  may  be  made  collectively  for  multiple 
applications.) 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

ins 

Start  Date 

Dur  (wk) 

0 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  —  _  lA 


Dei 

Con 


Input  from  ActiviP 


Input  via  Product: 


No  interact  dependencies  defined 


Output  via  Product: 


3.54:  Decision  to  Pigo  for  Full 
Evaluation 


Output  to  Activity; 


0.1:  Develop  and  Revise  SF21  MP 
0.2:  Develop  and  Revise  Checklist 
0.3:  Manage  Issues  and  Risks 
0.4:  Administer  SF21  Program 
10.1:  Plan  Joint  Evaluations 


Decision(s)  will  impact  the  contents  of  the  document  (s).  Decision  justifies  full  evaluation. 
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Overview  of  Activity  3.6:  Decision  -  Mission  Need 

Description:  The  sponsoring  line  of  business  submits  the  Mission  Need  Statement,  briefing  package,  and  any 
critical  supporting  material  to  members  of  the  JRC  before  the  decision  date,  as  specified  in  JRC  guidance 
provided  by  the  Program  Evaluation  Division.  The  sponsoring  line  of  business  presents  and  defends  the 
proposed  mission  need  to  the  Joint  Resources  Council.  Approval  of  the  MNS  at  the  Mission  Need  Decision 
by  the  JRC  establishes  the  mission  need  as  valid  and  authorizes  the  exploration  and  investment  analysis  of 
alternative  solutions  for  satisfying  the  need.  If  a  MNS  is  not  determined  to  be  valid,  it  is  returned  to  the 
sponsoring  line  of  business  for  disposition.  This  may  result  in  a  decision  by  the  sponsoring  line  of  business  to 
conduct  further  mission  analysis,  defer,  or  terminate  analysis  of  the  need. 

Plan  and  Perform:  N/A  POC  =  N/A 

Approve  or  Accept:  JRC  POC  =  JRC  Lead 

Products: 

3.6.1:  Mission  Need  Decision:  (This  decision  may  be  made  collectively  for  multiple  applications.) 


Schedule: 
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Full 
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Dependencies  and  Phases: 


Post  “n  ^  lA 


Dev 
Con 


0.5:  Coordinate  for  Decisions 

1.7:  Establish  Mission  Need 

■■FSSBS 

0.5.4:  FAA  Coord,  for  Decision  3.6 

1.7.1:  Mission  Need  Statement 

The  M^S  is  approvedMthe  Mission  Need  Decision.  ' 

No  interact  dependencies  defined 


Output  via  Product: 


Decisipnfs)  will  impdcfthe  contents  of  the  document(s). 


3.64;  Mission  Nepd  Decision  - Ti 


Output  to  Activity: 


j  04:  Develop  and  Revise  SF21  MP 
J0.2:  Develop  and  Revise  Checklist 
0.3:  Manage  Issues  and  Risks 
0.4:  Administer  SF21  Program 


1.8:  Develop  Requirements  Document 
12.5:  Conduct  Investment  Analysis 


The  definition  of  Mission  Need  initiates  investment  malysis  processes. 
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Overview  of  Aetivity  3.7:  Decision  -  Was  OpEval  Adequate? 

Description:  Was  the  OpEval  adequate  (i.e.,  Did  it  address  all  of  the  significant  issues?  Did  it  collect  the  data 
required  to  resolve  all  of  these  issues?  Is  the  analysis  of  the  OpEval  complete  and  have  all  significant  issues 
been  resolved?  Is  any  additional  evaluation  required?)?  Are  the  FAA  lines  of  business  ready  to  commit  to 
implement  the  application  in  a  timely  fashion  if  suitable  requests  (for  certification  and  operational  approval) 
are  received?  Activities  enabled  by  this  decision  are  shown  as  outputs  in  the  tables  that  follow.  (If  the 
application  were  to  require  FAA  investment  this  would  be  preceded  by  investment  analysis  per  AMS. 

The  Decision  on  OpEval  Adequacy  will  serve  as  a  major  or  minor  input  to  many  subsequent  Checklist 
activities.  For  simplicity  of  presentation,  only  the  most  important  interactions  are  shown  in  the  following 
tables. 

Plan  and  Perform:  N/A  POC  =  N/A 

Approve  or  Accept:  SF2 1  SSG  POC  =  AND-500  Lead 

Products: 

3.7.1:  OpEval  Adequacy  Decision:  (This  decision  may  be  made  collectively  for  multiple  applications.) 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

start  Date 

Dur  (wk) 

0 

LoE  (sm) 
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Dependencies  and  Phases: 

F 

Fu 
Lim  - 
Dev  -| 
Con  I 

Innut  from  Activity:  H  1 

^OS 

II- 

ll 

E 

1 

fi/ 

-s 

m 

tep 
-  Imp 
f—  T  ra 

It  Ins 

Input  via  Product: 

■1 

_I 

51 

n 

n 

■ 

0.5.5:  FAA  Coord,  for  Decision  3.7 

uikiaie  101  riecisions  | 

■I 

11 

j  PI 

11 

m 

■ 

Coordination  ofissues  with FAA  LOBs  us^  as  cm  input  to  SSG  decision  mcildng.  :y  i  ifym^l 

No  interact  dependencies  defined 


Output  via  Product: 

■ 

I 

6 

mm 

Hi 

V  Output  to  Activity: 

3,74:  OpEval  Adeqp^^^cy  Decision 

.... 

jO.l:  Develop  and  Revise  SF21  MP 

6 

1  1 

1 0.2:  Develop  and  Revise  Checklist 

0.3:  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program 

1.8:  Develop  Requirements  Document 
2.4:  Develop  Industry  Business  Cases 

2.5:  Conduct  Investment  Analysis 

Decision(s)  will  impact  the  contents  of  the  document(s).  OpEval  adequacy  decision  formlim  the  readiness 

to  proceed  to  investment  analysis.:-  r- 
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Overview  of  Activity  3.8:  Decision  -  Initial  Investment 

Description:  The  JRC  designates  the  alternative  solution  to  be  implemented,  approves  an  initial  Acquisition 
Program  Baseline  for  the  recommended  alternative  (no  variance  tracking),  and  approves  an  action  plan  that 
defines  the  cost,  schedule,  activities  (such  as  vendor  contract  award  for  first  production  system/first  site),  and 
documentation  required  to  mitigate  risk  and  better  define  requirements  in  preparation  for  a  final  investment 
decision. 

Plan  and  Perform:  N/A  POC  =  N/A 

Approve  or  Accept:  JRC  POC  =  JRC  Lead 

Products: 

3.8.1:  Initial  Investment  Decision:  (This  decision  may  be  made  collectively  for  multiple  applications.) 


Schedule: 
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Dev 
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Dependencies  and  Phases: 


Tra 


Input  from  Activity; 


0.5:  Coordinate  for  Decisions 

1.8:  Develop  Requirements  Document 

2.5:  Conduct  Investment  Analysis 


Input  via  Product; 


0.5.6:  FAA  Coord,  for  Decision  3.8 
1.8.2:  Final  Requirements  Document 
2.5.1:  Investment  Analysis  Report 
2.5.2:  Acquisition  Program  Baseline 
(APB) 


Th0  fHD  is  used  as  input  to  the  Initial  Investment  Deemap.  JA  Reports  exc  used  as  input  to  the Jnvestment 
Decisions, .  . '  ’  '  ' . . . . . . 


1.7:  Establish  Mission  Need 

■ 

■ 

r 

um 

m 

r 

1.7.1:  Mission  Need  Statement 

■ 

■ 

m 

mm 

mil 

■ 

b 

The  MNSis  revised,  if  necessary,  at  the  Initial  Investment  Decision^ 

No  interact  dependencies  defined 


Output  via  Product:  H 

:  m  m 

teii 

I 

■ 

Output  to  Activity: 

3.§.1:  Initial  Investment  Decision 

0 

M 

■Z 

0.1:  Develop  and  Revise  SF21  MP 

0.2:  Develop  and  Revise  Checklist 

0.3:  Manage  Issues  and  Risks 

0.4;  Administer  SF21  Program 

0.6:  Develop  Acquisition  Program  Plans 
6.3:  Develop  Ground  System  Specs 

7! 

Decision(s)  will  impact  the  contents  of  the  document(s).  The  Initial  Investment  Decision  initiates  the.  development 
'cf-pfo^amplansl^'-y-^  • 
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Overview  of  Activity  3.9:  Decision  "  Industry  Commits  to  Impl. 

Description:  The  applicant  formally  notifies  the  FAA  of  their  commitment  to  pursue  approval  and 

implementation  of  this  application,  either  at  specific  location(s)  or  NAS-wide.  [This  request  may  involve 
multiple  applications  or  it  may  be  for  this  application  alone.]  The  applicants  decision  will  be  based  on 
OpEval  results,  cost/benefit  analysis,  their  company  business  case,  and  other  considerations,  (in  coordination 
with  the  OCG)  activity  is  phases.  Activities  enabled  by  this  decision  are  shown  as  outputs  in  the  tables  that 
follow. 

The  Industry  Decision  to  Commit  to  Implementation  will  serve  as  a  major  or  minor  input  to  many  subsequent 
Checklist  activities.  For  simplicity  of  presentation,  only  the  most  important  interactions  are  shown  in  the 
following  tables. 

Plan  and  Perform:  N/A  POC  =  N/A 

Approve  or  Accept:  Industry  Stakeholders  POC  =  Various 

Products: 

3.9.1:  Formal  Notice  from  Applicants:  (This  letter  may  apply  to  multiple  applications.) 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

0 

LoE  (sm) 
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Dependencies  and  Phases: 

Ur 

Dev  “ 
Con  ^ 

F 

Fu 

n  - 

’os 

II- 

“ 

A 

fS 

tep 

In 

J 

np 
-  Tra 
r- Ins 

Input  from  Activity: 

5 

Input  via  Product: 

2.4:  Develop  Industry  Business  Cases 

T 

r 

r 

2.4.1;  Industry  Business  Cases 

■1 

■1 

■1 

Ml 

■1 

11 

!■ 

■ 

Industry  business  cqses  support  stakeholder  buy4n  to  equip/manufacture:- 

No  interact  dependencies  defined 


Output  via  Product:  ■  Output  to  Activity; 

-  '  .  '  '  ^  1  f  J  I  I  ck  t  .  _ 1 _ _ ji  rk _ 


3,94?  Fowar.Nptice  ft’QOt  Applicants  , 

'■  '  ■ 

lii 

1 

■■ 

B 

_ 0.1:  Develop  and  Revise  SF21  MP 

. 

_J 

1 

1 

1 0.2:  Develop  and  Revise  Checklist 

0.3;  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program 

11.2:  Plan  and  Apply  for  Avionics  Cert. 
12.1:  State  Intent  to  Conduct  New  Flight 
Ops  (Ph.  1) 

Decision(s)  will  impact  the  contents  of  the  c 
commitment. 

iocumentisf^Apidicmticatmnitmml^Mq^ 
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Overview  of  Aetivity  3.10:  Decision  -  Sel.  Vendor  &  Award  Contract 

Description:  The  selection  decision  is  based  on  the  stated  evaluation  criteria  including  cost  or  price 

considerations  to  identify  the  best  value.  The  Source  Selection  Official  (SSO),  usually  the  PT  Lead,  applies 
sound  business  judgment  to  the  evaluation  of  the  vendor's  proposed  solution  against  the  stated  evaluation 
criteria.  The  SSO  provides  a  rational  basis  for  the  screening  or  selection  decision. 

Plan  and  Perform:  N/A  POC  =  N/A 

Approve  or  Accept:  Product  Team  POC  =  PT  Lead 

Products: 

3.10.1:  Contract  Award:  (This  decision  may  be  made  collectively  for  multiple  applications.) 


Schedule: 


_ 

Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

start  Date 

Dur  (wk) 

0 

LoE  (sm) 
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Dependencies  and  Phases: 


0.5:  Coordinate  for  Decisions 

0.6:  Develop  Acquisition  Program  Plans 
0.7:  Prepare  Acquisition  Contract 

6.3:  Develop  Ground  System  Specs 

1 

SB 

I 

r 

0.5.7:  FAA  Coord,  for  Decision  3.10 

0.6.1:  Acquisition  Strategy  Paper 

0.6.2:  Program  WBS 

0.6.3:  Integrated  Program  Plan 

0.7.1:  Contract  Package 

0.7.2:  SIR/RFO 

6.3.1:  Ground  System  Design 
Specification 

6.3.2:  Interface  Documents 

ii 

8^1 

m 

ns 

19^ 

m 

m 

No  interact  dependencies  defined 


Output  via  Product:  H~ 

m  mm 

1  Output  to  Activity: 

340.1;  Contract  Award 

7 

J  0.1:  Develop  and  Revise  SF21  MP 

71  1  I 

1 0.2:  Develop  and  Revise  Checklist 

0.3:  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program 

3.11:  Decision  -  Final  Investment 

Decision(s)  will  impqct  the  contents  of  the  (ioci(menf(s).  Vendor  selection  is  used  as  input  to  the  Final  Investment 

:34fl5lt?Cqntra^|||i^rd  C" 

" : 

-  ' 

■If.. 

' 

_  9.3:  Manufacture  Gnd  Systems  for  Impl. 

_ 

7 

_  9.4:  Deliver  and  Integrate  Gnd  Systems 

Contract  award  initiates  the  development  of tl\e  firs)  production  ground  system.  The  contract  outlines 
requirements  for  delivery  and  integration  of  ground  systems.  y  .  , 
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Overview  of  Activity  3.11:  Decision  -  Final  Investment 

Description:  The  JRC  approves  the  program  for  implementation  and  assigns  it  to  the  appropriate  IPT,  approves 
the  Final  APB  for  program  execution  and  variance  tracking,  ratifies  and  baselines  the  Requirements 
Document,  commits  the  agency  to  full  lifecycle  funding  for  the  program,  and  identifies  future  corporate 
decisions  and  level  of  delegation. 

Plan  and  Perform:  N/A  POC  =  N/A 

Approve  or  Accept:  JRC  POC  =  JRC  Lead 

Products: 

3.11.1;  Final  Investment  Decision:  (This  decision  may  be  made  collectively  for  multiple  applications.) 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

0 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ^  r“  lA 


Input  from  Activity: 


0.5:  Coordinate  for  Decisions 
0.6:  Develop  Acquisition  Program  Plans 
0.7:  Prepare  Acquisition  Contract 
3.10:  Decision  -  Sel.  Vendor  &  Award 
Contract 

6.3:  Develop  Ground  System  Specs 


Input  via  Product: 


0.5.8:  FAA  Coord,  for  Decision  3.11 

0.6.1 :  Acquisition  Strategy  Paper 

0.6.2:  Program  WBS 

0.6.3:  Integrated  Program  Plan 

0.7.1:  Contract  Package 

0.7.2:  SIR/RFO 

3.10.1:  Contract  Award 

6.3.1 :  Ground  System  Design 

Specification 

6.3.2:  Interface  Documents 


Prqgam  planning  domments  used  as  guidance  in  mc^Wg  fiml  investment  decision.  Vendor  selection,  is  used  as 
input  to  the  Final  Investment  Decision.  - 


2.5:  Conduct  Investment  Analysis 


61 

1 

i<iwww.g 

i' 

2.5.1:  Investment  Analysis  Report 
2.5.2:  Acquisition  Program  Baseline 
(APB) 


M  Reports  are  used  as  input  to  the  Investment  Decisipns.  ■ 


No  interact  dependencies  defined 


Output  via  Product: _ ■■  ■ _ Output  to  Activity; 


3.114:  Final  Investment  Decision  <  , 

Decision(s)  will  impact  the  contents  of  thex 

■ 

^0.1:  Develop  and  Revise  SF21  MP 

1 

^0.2:  Develop  and  Revise  Checklist 

0.3:  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program 

iocument(s).  o  )  .  ..  .  r 

3.11.1;  Final  Investment  Decision  '  ‘ 

7 

□ 

□ 

1  •  xvxd.li u 111 rt?  Vjfiiu  k3^c^idii29  lui  xiii^i* 

The  Final  Investment  Decision  allows  the  program  0proceediwith  afull production  run. 
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Overview  of  Activity  3.12:  Decision  -  Formal  FAA/Union  Agreement 

Description:  Complete  formal  negotiation  with  the  FAA  unions.  Coordination  with  NATCA  is  required  for 
changes  that  affect  controllers.  [Coordination  with  PASS  is  required  for  changes  that  affect  maintenance 
personnel.]  Obtain  concurrence  with  the  changes  required  to  support  the  operational  use  of  this  application. 
Activities  enabled  by  this  decision  are  shown  as  outputs  in  the  tables  that  follow. 

Plan  and  Perforin:  N/A  POC  =  N/A 

Approve  or  Accept:  Unions,  With  FAA  Stakeholders  POC  =  Various 

Products: 

3.12.1:  FAA/Union  Agreement:  (This  decision  may  be  made  collectively  for  multiple  applications.) 

3.12.2:  NATCA  Concurrence  on  7110.65:  Air  Traffic  Control.  (This  order  may  be  revised  to  address 
procedural  changes  for  multiple  applications.) 

3.12.3:  NATCA  Concurrence  on  7210.3:  Facility  Operation  and  Administration 

3.12.4:  NATCA  Concurrence  on  7610.4:  Special  Military  Operations.  (This  order  may  be  revised  to  address 
procedural  changes  for  multiple  applications.) 

3.12.5:  NATCA  Concurrence  on  LOAs:  (These  LOAs  may  be  revised  to  address  procedural  changes  for 
multiple  applications.) 

3.12.6:  NATCA  Concur:  AIM:  (The  AIM  and  relevant  supplements  may  be  revised  to  address  procedural 
changes  for  multiple  applications.) 

3.12.7:  NATCA  Concur:  Training  Materials:  (This  material  may  be  developed  to  address  procedural 
changes  for  multiple  applications.) 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

0 

LoE  (sm) 
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Dependencies  and  Phases: 


i-IA 


0.5:  Coordinate  for  Decisions 

12.10:  Inform  Unions 

1 

u 

n 

L 

on 

0.5.9:  FAA  Coord,  for  Decision  3.12 
12.10.2:  NATCA  Response  to  7110.65 
12.10.3:  NATCA  Response  to  7210.3 
12.10.4:  NATCA  Response  to  7610.4 
12.10.5:  NATCA  Response  to  LOAs 
12.10.6:  NATCA  Response  to  AIM 
Revision 

12.10.7:  NATCA  Response  to  Controller 
Training  Mat'l 

m 

Bi 

Wi 

H 

1^  7  B 

Unicm  jeedbixk  W  the  t^  should  lead  toward  Qomemus.  . 

No  interact  dependencies  defined 


Output  via  Product; _ -  ■ _ Output  to  Activity; 


3.124:  FAA/Unioi»  Agreement 

' 

■ 

0.1:  Develop  and  Revise  SF21  MP 

0.2:  Develop  and  Revise  Checklist 

“ 

0.3:  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program 

IDecisionfs)  will  impact  the  contents  of  the  docMment(sf 

3.12.2:  NATCA  Concurr^pce  on  7110.65 
342.3j  NATCA  Concurrence  on  72103 
3.12.4;  NATCA  Copcprrence  on  7610.4 
3.12  5:  NATCA  Concurrence  on  LOAs  ' 

r 

1 

THzr 

12.6:  Revise  ATC  Orders  &  LOAs 

. L 

1  NA  TCA  concurrence  with  proposed  changes  required  to  implement  the  application. 

'AIJ:  Revise  the  AIM 

z 

NATCA^ncwrmce'ivithproposedchan^sreqtdredtomplemeritthe  application.  \ 

342.7:  NATCA  Concur;  Training 
Materials 

L. 

12.8:  Develop/Perform  Controller 

_ 

t 

— 

— 

. - 

L 

i  Training 

NA  TCA  concurrence  with  proposed  changes  required  to  implement  the  application. 
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Safe  Flight  21  Generic  Application  Checklist  -  September  28,  2001 

3.13:  Decision  -  In-Service 


Description:  A  decision  authority  (usually  the  sponsoring  LOB)  determines  if  the  procurement  was  developed  in 
such  a  that  users  welcome  it,  i.e.,  the  new  system  meets  requirements,  is  supportable  logistically,  functions 
easily  with  the  rest  of  the  NAS,  and  all  aspects  of  the  transition  to  operational  use  are  addressed  and  resolved. 
The  decision  authority  is  determined  by  the  Associate  Administrator  of  the  sponsoring  line  of  business 
working  in  conjunction  with  the  Acquisition  Executive  and  the  appropriate  IPT. 

Plan  and  Perform:  N/A  POC  =  N/A 

Approve  or  Accept:  IPT  POC  =  IPT  Lead 

Products: 

3.13,1:  In-Service  Decision:  (This  decision  may  be  made  collectively  for  multiple  applications.) 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

0 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  _  lA 


Dev 

Con 


Innut  from  Activity: 


0.5:  Coordinate  for  Decisions  I  \_ 

12,13:  Field  Test  Ground  Systems 


Reports  tisM  as  input  to  the  In-Service  Decision. 


_ Input  via  Product: _ 


0.5.10:  FAA  Coord,  for  Decision  3.13 
12.13.1:  Test  Reports 


No  interact  dependencies  defined 


Output  via  Product: 


Output  to  Activi 


I  ■[  1  ['  T  la  r  ~  l 0.1:  Develop  and  Revise  SF21  MP 

.  "  "  I  I  I  I  I  I  1^  1 0.2:  Develop  and  Revise  Checklist 

.  1  0.3:  Manage  Issues  and  Risks 

;  .  :  0.4:  Administer  SF21  Program 

3.13.1,;  Ip-Service  Detilslon  12.6:  Revise  ATC  Orders  &  LOAs 

.  _  ...5  12.7:  Revise  the  AIM 

12.8:  Develop/Perform  Controller 

;  .  ‘  ,  Training 

12.14:  Commission  Ground  Systems 

Decision(s)  will  impact  the  contents  of  the  dQcumm((s).  pie  In-Service  Decision  cpproves  the  commissioning 
'cmdoperati6naiiuse:f)f^6ui^"s^iems:Msiif^&^siWKtltil^S0SSl^ 

3,13.1:  In-Service  Decision  '  ,S - - — d—LI I  jti  ’  —1 9.3;  Manufacture  Gnd  Systems  for  Impl. 


The  In-Service  Decision  initiates  the  deployment  of  gromd systems,  to  all  sites.  ’■■■  ■  '  - 
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Overview  of  Activity  4.1:  Plan  Procedure  Development 

Description:  Based  on  the  operational  concept  and  the  current  maturity  of  the  application,  define  a  process  for 
developing,  testing,  and  demonstrating  the  procedures  that  are  necessary  to  support  the  operational  use  of  this 
application.  (This  plan  will  be  revised  as  needed  as  development  and  evaluation  progress.) 

Plan  and  Perform:  OCG  -  TOSG,  With  SF21  StG  -  Ops/Proc  SubGroup  POC  ==  OCG/TOSG  Rep 

Approve  or  Accept:  SF21  StG  -  Ops/Proc  SubGroup  POC  =  SF21  StG/OPsG  Co-chairs 

Products: 

4.1.1:  Procedures  Development  Plan:  Working  documentation  within  test-ops  for  refining  procedures 
through  simulation  and  HF  analysis.  This  product  is  published  as  part  of  the  Test  and  Evaluation  Master  Plan 
(TEMP).  This  plan  will  be  periodically  revised  on  an  as-needed  basis. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


Post- 
Full-n 
Urn  -I 
Dev  -I 
Con  -1 


■  Step 
r  Imp 
.-Tra 


1.1:  Define  High-Level  Concept  MM _ _ 1.1.1:  High-Level  Concept 

1.6:  Develop  Research  Evaluation  Plan  pi  I '  >  I  r  J  ,1  I  1.6.1:  Research  Evaluation  Plai 

High4evel  concept  provides  guidance  for  conducting  activity.  The  REPJdentifm  issues  thty  need  to  be 
addressed.  -  ,  '  " 


Innut  from  Activitv:  ■  H _ Input  via  Product: 


1.1.1:  High-Level  Concept 
1.6.1:  Research  Evaluation  Plan 


Interact  with  Activi 


0.1:  Develop  and  Revise  SF21  MP 
0.2:  Develop  and  Revise  Checklist 
0.3:  Manage  Issues  and  Risks 
0.4:  Administer  SF21  Program 
5.1:  Plan  Human  Factors  Activities 
8.1:  Plan  Coord.  Safety  Activities 


5.1:  Plan  Human  Factors  Activities  j  .  „"i  ,i,"  V- '■  .  •  '  ' ' 

8.1:  Plan  Coord.  Safety  Activities 

Provides  insight  into  refinement  of  interacting  activity  products  and  vice  versa:  May  Mbntif^  changes  .needed 
and  vice  versa):  -  ■  '  ■'  ''-.'V 


Output  via  Product: 


4.l4f  Procedpres  Development  Plan 
Provides  guidance  for  conduct  of  activity. ' 


Provides  guidance  for  conduct  of  activity. 


4.1.1:  Procedures  Development  Plan 

provides  guidance  for  conduct  of  activity. 


1111 


iTTTr 


Output  to  Activi 


4.2:  Specify  Procedures 


14.3:  Simulate  with  Pilots 
1 4.4:  Simulate  with  Controllers 


4.5:  Train  for  Procedures 
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Overview  of  Activity  4.2:  Specify  Procedures 

Description:  Based  on  the  operational  concept  and  with  input  from  pilots  and  controllers,  define  procedures  that 
are  necessary  to  support  the  operational  use  of  this  application.  Modify  these  procedures  as  necessary  based 
on  simulations  and  evaluations. 

Plan  and  Perform:  OCG  -  TOSG,  With  SF21  StG  -  Ops/Proc  SubGroup,  SC- 186  WGl  POC  =  OCG/TOSG  Rep 
Approve  or  Accept:  SF21  StG  -  Ops/Proc  SubGroup  POC  =  SF21  StG/OPsG  Co-chairs 

Products: 

4.2.1:  Procedures  Specification:  Working  documentation  within  test-ops  for  refining  procedures  through 
simulation  and  HF  analysis,  for  informal  input  other  groups  analyses  and  planning,  and  to  revising  the  (more 
formal)  detailed  concepts. 


Schedule: 


Con 

Dev 

Urn 

Full 

Post 

!A 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

20 

20 

20 

20 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  — •  lA 


De' 

Con 


Innut  from  Activity: 


Input  via  Product: 


1.1.1:  High-Level  Concept 


1.1:  Define  High-Level  Concept 


High-level  concept  provides  guidmce  for  condiictm^  activity: _ --- 


1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 
6.1:  Estimate  Performance 


Provides  guidance  Jar  conduct  Performance  estimates  provide  inptusdod^elopnimttf^^ 


4.1:  Plan  Procedure  Development  ||  1  Procedures  Development  Plan 


12  3 


1.2.1:  Detailed  OPS  Concepts 
1.3.1:  Detailed  Systems  Concepts 
6.1.1:  Performance  Expectations 


Wovidesguidmceforc^^^ 


4.3:  Simulate  with  Pilots 
4.4:  Simulate  with  Controllers 
5.2:  Analyze  Cockpit  Tasks 
5.5:  Analyze  Controller  Tasks 


4.5:  Train  for  Procedures 


4.3.1:  Pilot  Simulation  Report 
4.4.1:  Controller  Simulation  Report 
5.2.1:  Cockpit  Task  Analysis  Report 
5.5.1:  Controller  Task  Analysis  Report 


1 4.5.1:  Pilot  Training  Materials 
4.5.2:  Controller  Training  Materials 


Defines  and  formalizes  training  requirements. 


3 


Interact  with  Activi 


4.3:  Simulate  with  Pilots 
4.4:  Simulate  with  Controllers 
5.2:  Analyze  Cockpit  Tasks 
5.3:  Design  Cockpit  Interface 
5.5:  Analyze  Controller  Tasks 
5.6:  Design  Controller  Interface 
10.1:  Plan  Joint  Evaluations 
10.2:  Simulate  Mission 
10.3:  Conduct  Joint  Evaluation 


Existing  definitions  of  procedures  are  the,  starting  point  for  iateractions, with pilots  in  each  s,imuldtid 
modifications  to -procedures  ^ 

development  of  procedures.  Task  comlyses  provides  insight  into  procedure  developntent  an versd^^ff 
Evaluations  help  determine  limits  to  parameters  that  affect  the  performance  and  acceptabili^  of  procedures^.' ' 


7.2:  Define  Ground  System  Interop.  ■'  _  ’ ; 


iom  with  pilots  in  ^ach 


development  of  draft^^^^  may  impact  ground  system  interoperability  requirementsT and  vice  versa>  . 


8.2:  Summarize  Op.  Services  and  Env't  [  1  |2  [ 3  1 4 1  |  _ 

8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 


Safftycdnsiderationsitflmnce  the  specification  and  development  of  procedures  and  vice  versa f ' 


OutDut  via  Product: 


4.|.l^Procedur^-;Specificatipn:--; —  ^|^|  — j — | — | — ■ — ji.z,;  i»e 

Procedures  provide  input  to  the  definition  and  revisions  of  detailed  cdnce^^^ 


Output  to  Activit 


1.2:  Develop  Detailed  Ops  Concepts 
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4.2.1 :  Procedures  Specification  , , , 

Q 

1.8:  Develop  Requirements  Document 
12.6:  Revise  ATC  Orders  &  LOAs 

L 

___ 

A 

__ 

_ 

_ 

_ _ _ 

Results  of  activities  aid  in  the  development  ^requirements  documents.  Procedures  flown  at  OpEvql  provide 

4.2.1:  Procedures  Specification 

Initial  procedures  needed  for  refining  proa 

DZ 

4.3:  Simulate  with  Pilots 

4.4:  Simulate  with  Controllers 

.—j 

. 

idures  through  simulation  and  HF  analysis. 

4.2.1;  Procedures  Specification 

2 

B 

',T- 

4.5:  Train  for  Procedures 

8.6:  Ensure  Safety  of  Testing 

10.1:  Plan  Joint  Evaluations 

12.10:  Inform  Unions 

2 

T 

Initial  procedures  for  evaluations  are  basis  for  training  development.  Provides  information  on  expectations, 
requirements,  operational  sensitivities  4  mitigations..  Specification  defines  ^procedures  to.  be  flown  arid  data  to  be 
collected  during  evaluatidnSi  Provides  procedures  flown. during  evaluations  for  rewiewif  ,4. 

4.2.1:  Procedures  Specification;  ' 

n_ 

m 

»is 

: 

5.2:  Analyze  Cockpit  Tasks 

5.5:  Analyze  Controller  Tasks 

1 

. 

\lnitialproceduHs  are  basis  for  initiattask  analyses,  f  ;  r  , 

2 

B 

□ 

, 

.A;- 

11.2:  Plan  and  Apply  for  Avionics  Cert. 
12.1:  State  Intent  to  Conduct  New  Flight 

4.2.i :< Prdced'uHs  SpecificUtioha^  ; 1; . 'f ■ 

2^ 

4 

Ops  (Ph.  1) 

12.2:  Request  Operational  Approval 
(Ph.  2) 

Procedures  flown  af  OpEval  provide  partial  basis  for  approval.  Provides  partial  basis  for  statement  of  intent,  n 
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Overview  of  Activity  4.3:  Simulate  with  Pilots 

Description:  Beginning  from  initial  definitions  of  procedures,  conduct  and  evaluate  a  simulations  of  procedures 
with  pilots  and  identify  needed  modifications. 

Plan  and  Perform:  OCG  -  TOSG,  With  SF21  StG  -  Ops/Proc  SubGroup,  SC- 186  WGl  POC  =  OCG/TOSG  Rep 
Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

4.3.1:  Pilot  Simulation  Report:  Report  that  sumarrizes  the  results  of  pilot  simulations. 

Issues: 


-  Adequate  simulation  and  evaluation  of  worst-case  scenarios  may  not  be  achievable 

-  Identify  where  changes  may  be  needed  in  procedures  and  propose  alternatives 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

1 

1 

1 

LoE  (sm) 
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Dependencies  and  Phases: 

Fu 
Lim  - 
Dev  -I 
Con  “■■1  1 

Input  from  Activity:  H  1 

POJ 
II  > 

II 

>t- 

1/ 

rs 

-s 

tep 

Imp 

P"  T  ra 

Jr 'ns 

Input  via  Product: 

4.1:  Plan  Procedure  Development 

Dl 

1  {  1 

1 

L 

L_ 

4.1.1:  Procedures  Development  Plan 

■ 

D 

1 

11 

in 

11 

11 

11 

a 

1  Provides  guidance  for  conduct  of  activity.  ; , :  , ^  ;  ..  ,,  -  S  . . .  .  <  ,  , 

4.2:  Specify  Procedures 

Dl 

■1 

n 

11 

1" 

r 

r 

r 

n 

4.2.1:  Procedures  Specification 

Hil 

Dl 

11 

11 

IB 

11 

n 

n 

ID 

4.5:  Train  for  Procedures 

j 

3  4 

r 

r 

r 

r 

□ 

4.5.1:  Pilot  Training  Materials 

■ 

■ 

3^ 

■ 

41 

!■ 

11 

fIB 

11 

IB 

Training  materials  required  to  conduct  simulatioi 

Interact  with  Activity; 
4.2:  Specify  Procedures 
4.4:  Simulate  with  Controllers 
10.2:  Simulate  Mission 


Existing  definitions  of  proceduresim^  stcn^ting  point 


controlle?B'ayihtet&mdeBr^^^^^ 
[joint  evaluation  periods.  '  '  ' 


iihtimd 

‘■’.  i 


5.2:  Analyze  Cockpit  Tasks 
5.3:  Design  Cockpit  Interface 


2.3I4J 
2 


provides  insight  into  coctpit  interface  issues/design  a»rf  V/ce  Verm  *  *  ■  ^ 


Output  via  Product: 

B 

■  11 

1 

Output  to  Activity: 

4.3.1:  Pilot  Simulation  Report  . 

D 

B 

m 

m 

■ 

■ 

DB 

B 

B 

4.2:  Specify  Procedures 

D 

B 

j 

u 

□ 

1 

U 

□ 

Repoii^iSdmtify:0M^MlldHdri^sWedMjto.proK^duresT::igsg^Z'MSmMMSI^ 
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Overview  of  Activity  4.4:  Simulate  with  Controllers 

Description:  Beginning  from  initial  definitions  of  procedures,  conduct  and  evaluate  simulations  of  procedures 
with  controllers  and  identify  needed  modifications. 

Plan  and  Perform:  OCG  -  TOSG,  With  SF21  StG  -  Ops/Proc  SubGroup,  SC- 186  WGl  POC  =  OCG/TOSG  Rep 
Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

4.4.1 :  Controller  Simulation  Report:  Report  that  summarizes  the  results  of  controller  simulations. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

1 

1 

1 

LoE  (sm) 
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Dependencies  and  Phases: 

D( 

Con 

Input  from  Activity: 

Fi 

Lim 

n. 

Pos 

jII- 

“ 

lA 

fS 

tep 

Imp 
^  Tra 

Iplns 

■ 

'  m 

ra 

Input  via  Product: 

4.1:  Plan  Procedure  Development 

n 

■ 

■ 

n 

1  1  1 

1 

1 

r 

4.1.1:  Procedures  Development  Plan 

ml 

11 

11 

11 

H 

■ 

\Provides  guidance  for  conduct  of  activity, 

4.2:  Specify  Procedures 

3 

T 

7 

n 

4.2.1:  Procedures  Specification 

m 

D 

Bl 

Hi 

■1 

HI! 

11 

m 

m 

4.5:  Train  for  Procedures 

■HEMI 

■ 

■ 

■ 

4.5.2:  Controller  Training  Materials 

n 

■  3^ 

4  Bl 

HI 

■ 

Hi 

Training  materials  required  to  conduct  simulation. 

Interact  with  Activity: 


4.2:  Specify  Procedures 
4.3:  Simulate  with  Pilots 
10.2:  Simulate  Mission 


. 

, ; 'f  av':  '  «'v  * 


Existing  definitions  of  procedures  are  the  starting  foinijorMieracHoM'^^Jm^ 
modifications  to  procedures  (duringsimidatlon)  aMevatudiion^ofth^^^^^ 
development  of  procedures,  [Interleayedfoiisimultmepus^^^ 
simulations  exchange  potential proceSwh  ’h^justmmts  without  waitin^^^j 

77Aiun  «4A  >W4«  -  aM  v/aa  {a«aa>a-/aMtar‘':t>^&v^‘'V>«ayw7-a>»1*//.a'iav: 


5.5:  Analyze  Controller  Tasks 

2  ,.ff  ■::r 

5.6:  Design  Controller  Interface 

:ohtrolier''^roee^uresil^^iioil^B0^ick'^^‘fiaS^^^^':y:^^^^^^ 

Controller  task  analysis  provides  insight  into 

Output  via  Product: 

fl 

Output  to  Activity: 

4.4.1:  Controller  Simulation  Refjort  v,, 

■ 

a 

■ 

m 

m 

■ 

mmmm 

4.2:  Specify  Procedures 

A 

_ 

_ 

_ 

BBH 

Reports  identify  potential  changes  heeded  to  procedures,  ,  :  .  ^  ;  | 

no 
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Overview  of  Activity  4.5:  Train  for  Procedures 

Description:  Develop  training  materials  and  conduct  training  of  pilots  and  controllers  who  will  participate  in 
simulations,  evaluations,  and  operational  tests 

Plan  and  Perform:  OCG  POC  =  OCG/TOSG  Rep 

Approve  or  Accept:  ATP,  With  AFS  POC  =  TBD 

Products: 

4.5.1:  Pilot  Training  Materials:  Materials  used  to  train  pilots  on  the  procedures  to  be  used  for  evaluations. 

4.5.2:  Controller  Training  Materials:  Materials  used  to  train  controllers  on  the  procedures  to  be  used  for 
evaluations. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

2 

2 

LoE  (sm) 
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Dependencies  and  Phases: 


Input  from  Activity: 


4.1:  Plan  Procedure  Development 


Provides  guidance  for  conduct  of  activity. 


n 

t  :  ■  m 

!^lj 

rnH  Input  via  Product: 

1 

III! 

Bi  im 

1 T"#  •  X  •  A  1  o Lm  u  rwH  i/ w v  ^jio i  xr  nd-ii. 

■ 

2|31 . D 

□ 

1 

M 

n 

1 

m 

M 

HSMI 

■Ml 

■ 

4.2:  Specify  Procedures 


4.2.1:  Procedures  Specification 


Initial  procedures  for  evaluations  are  basis  for  trdining  development^^,  a  \ 


3141 

1  1 

□ 

3 

>:• 

■ ,  r#s 


'  'i  ’ 


Interact  with  Activity; 

8.6:  Ensure  Safety  of  Testing 

10.1:  Plan  Joint  Evaluations  _ 

Safety  strategies  identj^ed  at  the  time  that  training  materiatfdrydeyeidpe'd^^Phe 'Melted 


Aspeedi^th^  application  to  be  evaluated  and  thk  methods  of  eyatudtion  should  be  tefi^fe^f  the^ 
materialsfdhd  resources  must  be  budgeted for  training.  _  ''  ~  •  v.  i  /v" 


_ Output  via  Product: _ 

4.5.1:  Pilot  Training  Materials  >  ;  ' ^ 
4.5.2  :,C6tifili^'T|fiii 


1  ■  1:  S 

Output  to  Activity: 

:  IKI 

4.2:  Specify  Procedures 

[3141 

Defines  and forrhalizes  training  requirements,  ■ 


'4.5lKMiof¥Miniiiltliili^^^^^^ 
Training  materialsreguired  to  coriduci  sim 

ai 

. 

ip 

4.3:  Simulate  with  Pilots 

LL 

ulation^  vi  ,  .  .  \ 

s,, 

Itgl 

304 

BIWI 

w 

H 

12.2:  Request  Operational  Approval 
(Ph.  2) 

± 

□3 

4.5.2:;bon|r6ijle|ifrn^ 

■ 

■ 

m 

3  4 

m 

n 

m 

m 

m 

■ 

4.4:  Simulate  with  Controllers 

■ 

BQM 

■ 

j 

3 

4.5.2;  Controller  Traiiiing  MateHals  ’ 

a 

at 

3 

li 

12.8:  Develop/Perform  Controller 
Training 

__ 

S 

_ 

_ 

May  provide  basis  for  apjprbved  training.  - -  v-  r. 
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Overview  of  Activity  5.1:  Plan  Human  Factors  Activities 

Description:  Develop  a  Human  Factors  Plan  that  outlines  all  required  human  factors  analyses  and  other  related 
activities  that  will  need  to  be  conducted  to  support  the  development  of  the  application. 

Plan  and  Perform:  OCG  -  HFSG  POC  =  TBD 

Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

5.1.1:  Human  Factors  Plan:  This  HF  plan  provides  a  description  and  planned  schedule  of  all  required  human 
factors  analyses  and  other  related  activities  that  will  need  to  be  conducted  to  support  the  development  of  the 
application. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

8 

LoE  (sm) 
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1.1.1:  High-Level  Concept 
1.6.1:  Research  Evaluation  Plan 


1.1:  Define  High-Level  Concept 
1.6:  Develop  Research  Evaluation  Plan 


High-level  concept  provides  guidance  for  conducting  activity.  The  REP  identifies  issues  that  peed  to  be 
addressed,  v ' :  '  ■■'v.  ■ 


Interact  with  Activity: 


0.1:  Develop  and  Revise  SF21  MP  m _ 

0.2:  Develop  and  Revise  Checklist  p»  _ _ _  I . . ~1' 5.  f  1,  ; 

0.3:  Manage  Issues  and  Risks 
0.4:  Administer  SF21  Program 
4.1:  Plan  Procedure  Development 
8.1:  Plan  Coord.  Safety  Activities 

Provides  insisht  iniO:refinement  ofinteractmiWifvj[^m^^^W0m^S^^Bi^^^^^^^z&^^M^^ 
previewing  safety  issues  in  drafting  the  HF  plan  will  InfTuence  the  strategy  for  analysis  and  development. 


fS'.' 


Output  to  Activity 


Output  via  Product: 


5.1.1:  Human  Factoid  Plah  ;  1 

n  15.2:  Analvze  Cockpit  Tasks 

1  1 1  1  1  1  1 5.3:  Design  Cockpit  Interface 

5.5:  Analyze  Controller  Tasks 

5.6:  Design  Controller  Interface 

Provides  guidelines  for  subsequent  human  factors  analyses.  ;  ;xV 

5.1.1  ;.'.HSt'fi|il|Pigliij^Blf 

Define  Cockpit  Interface  Stds 

Provides  guidelines  for  subsequent  Kunian  factors  analyses.  '  !- 

Safe  Flight  21  Generic  Application  Checklist  -  September  28,  2001 


Dependencies  and  Phases: 


Input  from  Activity: 


Post  ■ 
Full-. 
Lim  -| 

Dev  -| 

Con  -I 


Step 
p  Imp 
i-Tra 


Input  via  Product: 
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Overview  of  Activity  5.2:  Analyze  Cockpit  Tasks 

Description;  Conduct  a  cockpit  human  factors  task  analysis.  During  limited  evaluation  and  OpEval  activities, 
this  analysis  is  conducted  jointly  with  a  corresponding  controller  human  factors  analysis. 

Plan  and  Perform:  OCG  -  HFSG  POC  =  TBD 

Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

5.2.1:  Cockpit  Task  Analysis  Report:  This  document  presents  summary  results  of  the  initial  analysis, 
including  task  identifications,  issues  and  risks,  and  recommended  computer-human  interface  (CHI)  design 
requirements  if  appropriate.  The  analysis  is  based  on  initial  application  concepts  and  procedures,  and  is  used 
to  support  the  subsequent  analysis  of  cockpit  human  factors. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

24 

24 

16 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  • 
Full-, 
Lim  -j 
Dev-| 

Con  —1  I 


Step 
p  Imp 
.-Tra 


Innut  from  Activity:  Input  via  Product: 


1.1:  Define  High-Levei  Concept  MM _ 1.1.1:  High-Level  Concept 

4.2:  Specify  Procedures  M  I  i  I  I  ■  I  I  I  4.2.1:  Procedures  Specification 

High-level  concept  proyides  guidance  for  conducting  activity.  Initial  procedures  are  basis  for  initial  tg^k 


analyses:  ■  - 


1.2:  Develop  Detailed  Ops  Concepts 


Provides  guidance  for  conduct  of  activity. 


5.1:  Plan  Human  Factors  Activities 


Provides  guidelines  for  subsequent  human  factors  analyses. 


5.3:  Design  Cockpit  Interface  l-^-j - : - 


1.2.1:  Detailed  OPS  Concepts 


5.1.1:  Human  Factors  Plan 


5.3.1:  Cockpit  Interface  Design 


Initial  cockpit  interface  design  required for  initial  cockpit  task  analysis.  ■  . . ^  \ , 


|2|3|  I  I  I  I _ 6.1.1:  Performance  Expectations 

.  6.1.2:  Estimated  Performance 
Requirements 


Performance  estimates  provide  inputs  to  development  of  hitman  factors  criteria  and  subsequent  task  analyses. , 


6.1:  Estimate  Performance 


1  02  3 


Interact  with  Activit 


4,2:  Specify  Procedures  1 3  1 4 J _ _ \  .  <  ■<  m' 

9.1:  Develop  Avionics  r  .  KijEj _ L^J 

10.1:  Plan  Joint  Evaluations  ‘  ^  ^ 

10.2:  Simulate  Mission  M-v  ‘  :;-r" 

10.3:  Conduct  Joint  Evaluation  I  *  V  .  r  4> »  L  ‘^**-  *  *  ^  M;  *  '  “  J  J 

Task  analyses  provides  insight  into  procedufi,^fievelopnPMtMiIyiciJeemaj!Afi6hicsdevelopthenifdenpfies.'\yhat: 
the  pilot  needs  to  do  with  avionics.  Cockpitj^k  cmalyM:f^aiukim  requirements  wiU  effecfplanning  for  tests^ 
and  evaluations,  and  vice  versa.  Cockpit  task  analyses  arepeifoi^ed  in' conjunction  Mih  Joint  evaluations i  “ 


4.3:  Simulate  with  Pilots  213141  I  I  I  .'fSf :  v' .  ■  ■ ; ;  f  'rf M;'  f  ,  ' 

5.3:  Design  Cockpit  Interlace  '  ^  ' 

Cockpit  task  analysis  provides  insight  into  pilot  : ; 

provides  insight  into  cockpit  interface  design,  and vice  versd.  ,  . . 4 


8.2:  Summarize  Op.  Services  and  Env  t  | 

8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs  | 

d 


I  H3  4 


'P 

* 


Output  via  Product: 


Output  to  Activi 


5.2.1:  Cockpit  Task  Analysis  Report  ,  — _ M hi —a j  2:  Develop  Detailed  Ops  Concepts 

••  • ,“ M"  •'  17I..  I  I  J  _ 

Task  analyses  provide  input  io  the^definition  and  revisions  of  detailed. concepts:  4  ■  \  ■  S;  Me 


5.2.1:  dockpit  Task Xihalpis  Report - 4  2:  Specify  Procedures 

Reports  idemify  potential  changes  needed  to  procedures.  ^  !■  7-  . .  *  '■  -  ■  '  :  :  ;  -  ; 
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5.24;  Cockpit  Task  Analysis  Report 

□ 

— 

— 

_ 

L_ 

5.3:  Design  Cockpit  Interface 

Characterizes  basis  for  development  of  initial  dOckpit  interface  desigt 

5.24;  Cockpit  Task  Analysis  Report  ^ 

- 

2 

tr;,. 

8.6:  Ensure  Safety  of  Testing 

z 

211 

\Prdvides  information  on  expectatiorisy  requirements,  operational  sensitivities  &  mitigations.  .  < 

5.2.1:  Cockpit  Task  Analysis  Report 

'  '  ' 

2 

EKl 

2|3 

•r 

!i;' 

_ 

12.2:  Request  Operational  Approval 

_ 

_ 

_ 

_ 

4| 

_ 

(Ph.  2) 

.  .  I  . . . . . J ^ 

Important  ingredient  to  Ops  Approval  consideration. 
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Overview  of  Activity  5.3:  Design  Cockpit  Interface 

Description:  Develop  and  refine  the  cockpit  interface  design  based  on  the  cockpit  task  analysis.  This  provides 
the  input  to  the  interface  standards  development  activity  once  the  interface  design  has  been  matured  and 
validated. 

Plan  and  Perform:  OCG  -  TOSG  POC  =  OCG/TOSG  Rep 

Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

5.3.1:  Cockpit  Interface  Design:  Working  documentation  specifying  the  functions,  sumbology,  organization, 
and  interactions  of  cockpit  crew  interfaces  that  enable  the  application. 

5.3.2:  Mock-Ups  or  Simulation  Avionics:  For  refining  interfaces  and  simulation  and  FIF  evaluation  with 
pilots. 


Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

24 

24 

12 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-, 
Urn  -j 
Dev  -I 
Con  -n 


Step 
r  Imp 
i-Tra 


Innut  from  Activity: 


Input  via  Product: 


1.3:  Develop  Detailed  Systems  Concepts 


Provides  guidance  for  conduct  of  activity. 


5.1:  Plan  Human  Factors  Activities 


I  n  1  1 


Provides  guidelines  for  subsequent  human  factors  ancflysesir 


5.2:  Analyze  Cockpit  Tasks 

fihie 


1.3.1:  Detailed  Systems  Concepts 


5.1.1:  Human  Factors  Plan 


5.2.1:  Cockpit  Task  Analysis  Report 


Characterizes 


6.1:  Estimate  Performance 


6.1.1:  Performance  Expectations 
6.1.2:  Estimated  Performance 
Requirements 


Performance  estimates  provide  inputs  to  development  of  interfaces,  '  -  ■  . 


Interact  with  Activi 


4.2:  Specify  Procedures 
7.3:  Validate  Interoperability 
9.1:  Develop  Avionics 
10.2:  Simulate  Mission 
10.3:  Conduct  Joint  Evaluation 


Task  analyses  provides  insight  into  procedure  development 

joint  evaluations  provide  insight  into  interface  4esigftevaln0om,mdjipey^^0]Eyctltt(alp^^££^^^pj^efface 

provides  insight  for  avionics  development  qntjyice  versa  ^opfpit  imicpnalyses-arepetfpp^^M^^^dJj^^^^^ 
with  joint  evaluations.  ‘  '  ■ 


4.3:  Simulate  with  Pilots 
5.2:  Analyze  Cockpit  Tasks 


Copkpit Simulation  provides  insight  into  cockpit  interface  issu^^esign  anaviceypr^^j^ 
provUfes  insight  into  cockpit  interface  design,  and  vice  versa^j^f':'t''-:fp§MW^ 


8.2:  Summarize  Op.  Services  and  Env't  1112 
8.3:  Perform  Safety  Analyses 

8.4:  Allocate  Safety  Objs  &  Reqs  ^  . 

Safety  consideratidhS  influence  task  analyses  and  vice  versa. 


3i4 


I  B3'4 


Hi 


Output  to  Activi 


_  .  _  .  .  21Ki  is  T  1 1.3:  Develop  Detailed  Systems  Concepts 

5.3.1;  Cockpit  Interfqpe  Design  jlSDlLT±±±J6.1:  Estimate  Performance 

Cockpit  interface  requirements  provide  input  tojhe  t^efinitipn  and  revisions  of  detailed  concepjs.  Revisions  to 
cocl^it  interface  may  change  estimated  requirements  or  capabilities.  _ • 


Outnut  via  Product: 


5,3,1:'. Cockpit  Inter%cc,Design;:'  J*'  ^  ^ - 5.2:  Analyze  Cockpit  Tasks 

Initial  cockpit  interface  dest^required far  initial  coclp^^  ■  - 


5.3.1;  Cockpit  Interface  Design^^^^^^^  -*^  — js  4.  Define  Cockpit  Interface  Stds 

Pfdvmes  basis fdr^eftrdngd^  ihtet^ce'StandcmdesimSjM^^  ^ 
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5.3.1:  Cockpit  Interface  Design 

m 

H 

314 

BB 

■ 

■ 

B 

1  19.1:  Develop  Avionics 

4.. 

1  1 11.2:  Plan  and  Appiv  for  Avionics  Cert. 

11.4:  Submit  Updated/Supp. 

Information 

Interface  designs  are  used  to  support  avionics  development.  Preliminary  designs  provide  an  input  ^to  certification 
plan  if  standards  are  not  ready.  '  ,  . 

5.3.1;  Cockpit  Interface  Design 

5.3.2:  Mock-Ups  or  Simulation  Avionics 

Human  factors  analyses  are  required  topla 

2 

_ 

2|3 

u 

u 

— I — — j  10.1:  Plan  Joint  Evaluations 

n  the  mission  simulation.  ■  .  -  , 
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Overview  of  Activity  5.4:  Define  Cockpit  Interface  Stds 

Description:  This  activity  defines  the  standards  to  be  used  when  developing  and  manufacturing  avionics  to 
support  the  application. 

Plan  and  Perform:  SAE  POC  =  TBD 

Approve  or  Accept:  SAE  POC  =  TBD 

Products: 

5.4.1:  Cockpit  Interface  Standard:  This  document  provides  standards  upon  which  subsequent  avionics 
interface  implementation  and  applications  for  certification  and  approval  are  based. 


Schedule: 


Con 

Dev 

LIm 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-| 
Urn  -1 
Dev-| 

Con  —1 


Step 
r  Imp 
r-Tra 


Innut  from  Activity: 


1.3:  Develop  Detailed  Systems  Concepts 

8.7:  Assess  Comparative  Safely  ,  :  ,  8.8.1:  AC  on  ADS-B/CDTI  Capabi] 

8.0.  Formalize  Scopes  of  Operations  t,  .  '  ,  it* 

,  w  <  .  >  „  >  Levels  and  Lims 

Systems  concepts  support  standards  development.  CSA  provides  guidance  in  development  of  standards.  AC 
pr&vidfiiiripiiti&M^loprnent  of  requirements  and  standards.  "  >  ’ : 


Input  via  Product: 


1.3.1:  Detailed  Systems  Concepts 
I .  I  8.7.1:  Comparative  Safety  Analysis 
'  5'r  8.8.1:  AC  on  ADS-B/CDTI  Capability 

Levels  and  Lims 


5.1:  Plan  Human  Factors  Activities 


Provides  guidelines  for  subsequent  human  factors  analyses^! 


5.3:  Design  Cockpit  Interface 


Provides  basis  for  defining  avionics  interface  standards. 


5.1.1:  Human  Factors  Plan 


5.3.1:  Cockpit  Interface  Design 


Interact  with  Activit 


6,2:  Define  Performance  Standards 

6 

m 

Cockpit  interface  standards  definition  provide  insight 

into  tde  definition 

"  "  '  '  5'“  . 

'  ,  .  s'*,  V  '!.«  liW  ,  .  si' J 

0f  avionics  perj 

brmance  standardsjtand 

vice  versif  y  ■  \  '  •  ,  ,■ 

,"K  '  '  ■■••.■/'•■’ft  iS- 

Output  via  Product: 


Output  to  Activi 


I  I  "I  ■[  ^  '  I  I '  19.1:  Develop  Avionics 

11.2:  Plan  and  Apply  for  Avionics  Cert. 

^  . .  . . 11.4:  Submit  UpJlted/Snpp. 

’ '  Information 

Standards  provide  baseline  upotiywhich final  avionics  designs  are  developed  -  use  if  available,  otherwise  use  , . 
preliminary  designs.  Completion  of  interface  standards  (with  performance  standards)  facilitates  certificatipn  by 
TSO:  Data  input  for  certification.  '  •  .  '' ' 
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Overview  of  Activity  5.5:  Analyze  Controller  Tasks 

Description:  Conduct  a  controller  human  factors  task  analysis.  During  limited  data  collection  and  OpEval 
activities,  this  analysis  is  conducted  jointly  with  a  corresponding  cockpit  human  factors  analysis. 

Plan  and  Perform:  OCG  -  HFSG  POC  =  TBD 

Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

5.5.1:  Controller  Task  Analysis  Report:  This  document  presents  summary  results  of  the  analysis,  including 
task  identifications,  issues  and  risks.  The  analysis  is  based  on  analyses  and  evaluations  previously  conducted 
(if  applicable),  as  well  as  revised  procedures,  and  is  performed  as  part  of  current  evaluation  activities.  The 
results  of  the  analysis  are  used  to  support  subsequent  planning  efforts  and  stakeholder  commitments. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

24 

24 

16 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


F 

Lim 
Dev 
Con 


Input  from  Activity:  H  H  Input  via  Product: 


1.1:  Define  High-Level  Concept  yM _ 1.1.1:  High-Level  Concept 

4.2:  Specify  Procedures  II-  I  ;:J\  4.2.1:  Procedures  Specification 

High-level  concept  provides  guidance  for  conducting  activity., Initial  procedures  are  basis  for  initial  task 


1.2:  Develop  Detailed  Ops  Concepts 


Provides  guidance  for  conduct  of  activity. 


2  3 


5.1:  Plan  Human  Factors  Activities 


1  D 1  1 


Provides  guidelines  for  subsequent  human  factors  dnalyses.ff-  ;'?  • 


5.6:  Design  Controller  Interface 


1.2.1:  Detailed  OPS  Concepts 


5.1.1:  Human  Factors  Plan 


5.6.1:  Controller  Interface  Design 


Initial  controller  interface  designrequired for  initial  controller  task  analysis.  . " 


1 1  |2|3  I  I _ 6.1.1:  Performance  Expectations 

6.1:  Estimate  Performance  Estimated  Performance 

I  '  Requirements 

Performance  estimates  provide  inputs  to  development  of  hurhart factors  criteria  and  subsegtient  task  ahalyses^^ 


Interact  with  Activit 


4.2:  Specify  Procedures 
10.1:  Plan  Joint  Evaluations 
10.2:  Simulate  Mission 
10.3:  Conduct  Joint  Evaluation 


7'ask  analyses  provides  insight  into  procedure  development  and  vice  versd' 
revised  in  conjunction  with  procedure  adjustments  in  mission  simutMlm  ah^  evalucidpH 
analyses  are  performed  in  conjunction  Vi>ith  jdiht  evaludtidnjTffp^lk  ’5'; 


4.4:  Simulate  with  Controllers  _ [ 

5.6:  Design  Controller  Interface  '  ^  fmI  --  f'&i.':' 

Controller  task  analysis  provides  insight  into  eontroller:prdcedure:SMmatidnsi^iama§fM^ 
analysis  provides  insight  ihtd  Controller  interface  design,  ctnd  itce perS(^:^^.i:\ _ r  : 


8.2:  Summarize  Op.  Services  and  Env't  111  2  |3J4 1 _ - 

8.3:  Perform  Safety  Analyses  11 2  fJISi  j.,, 

8.4:  Allocate  Safety  Objs  &  Reqs  |  ,  .  A  j  l  :,  ;  !  ^ 

Safety  considerations  influence  task  analyses  and  vice  iefsa.  •  ^ 


Outnut  via  Product: 


Output  to  Activi 


5.5.1:  Corifroiler  Ta8k''Anal;;^iS;^Re]^rt; :  —  ^  U;  Develop  Detailed  Ops  Concepts 

Task  andiysefprb^idefripui  to,  the  definition  and  reyisiqns,offietahed;Cpncepts.:t:i^^^^^^^  " 


.  .3.  I,,  ..V  1 .  h.  O-i'.-  ■“•I  1.8:  Develop  Requirements  Document 

5.5.1:  ControIIei;  Task  Analysis  Report - mT . T . t1t2.6:  Revise  ATC  Orders  &  LOAs 


Results  of  activitiesfiid  in  the  development  of  requirements  documents.  Analysis  helps  define  what  needs  to  be 
revised  iti^TC  (>ders'dnd  '■  V';"-’"'"./- .s 
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5.5.1 :  Controller  Task  Analysis  Report  - 

2 

2 

t 

4.2;  Specify  Procedures 

\Reporis  identify  potential  changes  needed  to  procedures,  :  > 

55,1 ;  Controller  T^slc  Analysis  Report  1 

E: 

— j- 

"T 

B 

5.6:  Design  Controller  Interface 

[Results  cf  controller  task  analyses  provide  thefyameworkforcpntroller  inte^fyice  design.  -  ^  ^ 

5.5.1;  Controller  Task  Analysis  Report  - 

-2| 

i_. 

2|3 

TT 

B 

8.6:  Ensure  Safety  of  Testing 

Provides  information  on  expectations,  requir 

enter 

, 

1 

1 

sens 

Uivjities  MMitigatims.  , 
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Overview  of  Activity  5.6:  Design  Controller  Interface 

Description:  Develop  and  refine  the  ATC  interface  design  based  on  the  controller  task  analysis.  This  provides 
the  input  to  the  interface  specification  development  activity  once  the  interface  design  has  been  matured  and 
validated. 

Plan  and  Perform:  SF21  Program  Office,  With  ATP,  AUA,  OCG  POC  =  SF21  Progam  Lead 

Approve  or  Accept:  SF21  Program  Office,  With  ATS,  SF21  Program  Office  POC  =  SF21  Progam  Lead 

Products: 

5.6.1:  Controller  Interface  Design:  Interim  design  requirements  for  controller  (automation)  interfaces  to 
support  the  development  of  the  application. 

5.6.2:  Mock-Ups  or  Simulation  Gnd  Eqpt:  For  refining  interfaces  and  simulation  and  HF  evaluation  with 
controllers. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

12 

12 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


De\ 

Con 


Innut  from  Activity: 


1.3:  Develop  Detailed  Systems  Concepts 


Provides  guidance  for  conduct  of  activity. 


5.1:  Plan  Human  Factors  Activities 


1 


1  I 


Provides  guidelines  for  subsequent  human  fcK^td^s'^qlyses. 


5.5:  Analyze  Controller  Tasks 


Results  c 


Input  via  Product: 


1.3.1:  Detailed  Systems  Concepts 


5.1.1:  Human  Factors  Plan 


5.5.1:  Controller  Task  Analysis  Report 


m 


6.1:  Estimate  Performance 


Performance  estimates  provide inputs  to  development  of  interfaces. 


6.1.1:  Performance  Expectations 
6.1.2:  Estimated  Performance 
Requirements 


Interact  with  Activi 


4.2:  Specify  Procedures  _ _ 

7.3:  Validate  Interoperability  'liA 

9.2:  Develop  Ground  Systems  for  Eval.  hpfi 

10.2:  Simulate  Mission  _  "  ^ 

10.3:  Conduct  Joint  Evaluation 

Task  analyses  provides  insight  into  procedure  versa,  InteroperUUity  validcitidns  during 

joint  evaluations  provide  insight  into  interface  ^fsi^yvaluatjon^,  and  vice  versa, .Conp’oljef  interface  desi^ 
will  impact  development  of  ground  systems  and  y(^fversdlCpnirpllertc^^  analyses  are  perfprmpd  itijSpl'  ' 
conjunction  wi^ii joint 


4.4:  Simulate  with  Controllers  _ _2_^ _ 

5.5:  Analyze  Controller  Tasks  -.d  2 

Controller  task  analysis  provides  insight  into  controller  J^pcedwe  ^^d  Vtce,  ve^f  -.CoptrptleS,^ 

analysis  provides  insight  into  controller  interface  design,  and  vice  versa  '■  ”1^ 


8.2:  Summarize  Op.  Services  and  Env't  1 1 1 2 1 3  |4 1 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 


H3  4 


Output  via  Product: 


Controller  Interface  Design 


Output  to  Activi 


1.3:  Develop  Detailed  Systems  Concepts 
. . . ^  _ _ _ _ _ LJ _ 1 6,1 :  Estimate  Performance 

Results  of  controller  interface,  design  used  as  input  to  detailed  systems  concepts.  Qontrolleijnterface  design  used 
as  input  to  performance  estimates.  '  - •  ■  .  .  ' 


S.tf.J;, Controller  Interfece  Design  - - j —  1.8:  Develop  Requirements  Document 

Results  of  controller  interface  designvsed  as  input  to  defining  requirements,  •  :  ■  ‘ 


5.04'  Controller  Interface  Design  re  - — js.S:  Analyze  Controller  Tasks 

Initial  controller  interface  design  required  for  initial  controller  task  analysis,  • 
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5.6.1;  Controller  Interface  Design 

2H 

E 

. 

9.2:  Develop  Ground  Systems  for  Eval. 
10.1:  Plan  Joint  Evaluations 

5.6.2:  Mock-Ups  or  Simulation  Gnd 

1  1 

“ 

Interface  designs  are  used  to  support  ground  systems  development.  Human  factors  analysesi^are  required  to  plan 
the  missiioii  simulation.  ' . . 

128 


Safe  Flight  21  Generic  Application  Checklist  -  September  28, 2001 

Overview  of  Activity  6.1 :  Estimate  Performance 

Description:  Develop  estimates  for  required  performance  to  support  the  development  and  evaluation  of  the 
application.  Data  is  collected  throughout  simulations  and  OpEvals,  and  is  used  to  validate  and/or  revise  initial 
estimates.  The  output  of  this  activity  will  eventually  drive  the  establishment  and/or  revision  of  performance 
and  technical  standards. 

Plan  and  Perform:  OCG  POC  =  OCG  Co-chairs 

Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

6.1.1:  Performance  Expectations:  These  expectations  are  developed  with  initial  or  revised  Ops  and  system 
concepts  based  on  the  knowledge  and  experience  available  at  that  time.  These  expectations  guide  the 
planning  and  conduct  of  simulations  and  evaluations.  They  also  guide  procedures  development  and  data 
collection  requirements  for  later  evaluation  activities.  At  several  points  during  the  process,  this  product  is 
modified  as  needed. 

6.1.2:  Estimated  Performance  Requirements:  These  estimates  are  developed  with  initial  Ops  and  system 
concepts  based  on  the  knowledge  and  experience  available  at  that  point  in  time.  In  the  Concept  Phase, 
estimated  performance  requirements  provide  guidance  in  assessing  the  trade-offs  between  alternative  systems 
to  support  application  refinement.  Estimated  performance  requirements  provide  a  basis  of  comparison 
between  systems  that  will  support  subsequent  simulations/evaluations  and  the  performance  required  to 
support  the  application. 

6.1.3:  Performance  Data  Collection  Requirements:  These  requirements  provide  inputs  into  the  planning 
and  conduct  of  simulation  and  evaluation  activities,  to  better  characterize  performance  capabilities  and 
requirements. 

Issues: 


-  Need  to  determine  how  estimates  of  UAT  and  VDL  Mode  4  performance  will  be  made  in  the  absence  of 
pre-existing  (draft)  standards 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Tra 

Ins 

Start  Date 

Dur  (wk) 

16 

16 

8 

2 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-. 
Lim  -1 
Dev-| 

Con  —1  I 


Step 
p  Imp 
.-Tra 


1 


1.1:  Define  High-Level  Concept 


High-level  concept  provides  guidance  for  conducting  activity. 


3.4:  Decision  -  Select  Link(s) 


The  Link  Decision  is  required  to  refine  performance  estimates,  r; 


Input  via  Product: 


1.1.1:  High-Level  Concept 


3.4.1:  Link  Decision 


5.3:  Design  Cockpit  Interface 
5.6:  Design  Controller  Interface 
8.2:  Summarize  Op.  Services  and  Env't 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 


_ _  5.3.1:  Cockpit  Interface  Design 

I  rl  •  5.6.1:  Controller  Interface  Design 

8.2.1:  Operational  Services  and  Env't 
■  ■  Definition 

8.3.1:  Operational  Hazard  Assessment 
V  8.3.2:  Hazard  Analysis  (PHA  or 
SSHA/SHA) 

8.4.1:  ASOR 


Revisions  to  cockpit  interface  may  change  estlmdtedfequireMents  or  capabilities.  Controller  interface  design  . 
used  as  input  to  performance  estimates.  Safety  fionsideratlohs  and  thefieedfqr  sqfety-releyant  specifics  will  i 


7.2:  Define  Ground  System  Interop. 

nUInliiwHliiililiiiH 

7.2.1:  Estimated  Interface  Reqs 

Interoperability  assessments  provide  inputs  to  refinemeht  of  performance  estipiates,  : 

7.3:  Validate  Interoperability 

9.1:  Develop  Avionics 

9.2:  Develop  Ground  Systems  for  Eval. 

10.3:  Conduct  Joint  Evaluation 


7.3.1:  Interoperability  Validation 
Report 

9.1.1:  Avionics 

9.2.1:  Ground  Systems  for  Evaluation 
10.3.1:  Joint  Evaluation  Data 

a Tfocitlttc  n/'cllcAiPm 


Interoperability  assessments  provide  inputs  to  refineihent  of peiformance  estimates.  Results  of  system 
development  used  as  input  to  estimating  performance.  Evaluation  results  enable  validation  of  performance 
models  and  assumptions.  ;  ■  -  •  •  .  '  Vf!' 


Interact  with  Activif 


1.2:  Develop  Detailed  Ops  Concepts  2  1 3j  5 _ 

1.3:  Develop  Detailed  Systems  Concepts  ■I2m  iBl ■  'I-  '  ‘ 

Revisions  to  detailed  concepts  provides  insipht  into  re finetnehts  of 

Development  of  detailed  concepts  provides  insight  into'rbfihiemehisof^ipfyfpfi^fmfic^^^^^Hdiffi^S^', 


7.1:  Analyze  Interoperability  F  I  I  I  I  ■  M  :  ; 

Revisions  to  performance  estimates  provide  insight  into  analysis  of  inter^pPrb^flii^'arkivice.fS^sd 


Output  via  Product: 


6.1.1;  Performance  Expectations  :  ■  — ^^0.5:Coortl 

Provides  inputs  to  FAA  decision  making.  ... 


6.LlrPerlbrmaHcig?Ext>ectations^::|:ftyg  ■  pi  '  l  .  ’'-I  "I 

6.L2:'EsIiinat^ Performance V  I  |3l . | . | . . j . J  1.5:  Perfoi 

Requirements  K 

Performance  estimates  guide  the  design  and  development  of  data  link  equipment 


Output  to  Activi 


0.5:  Coordinate  for  Decisions 


1.5:  Perform  Link  Assessment 
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6.1.1;  Performance  Expectations 

H" 

1 

j4.2:  Specify  Procedures 

m. 

1  I 

J  10.2:  Simulate  Mission 

10.3:  Conduct  Joint  Evaluation 

11.1:  Obtain  Spectrum 

Performance  estimates  provide  inp^uts  to  development  of  procedures.  Provides  inputs  to  development  of  joint  r, 
evaluation  parameters.  Provides  guidance  for  alloCatin^assi^ing  spectrum  for  Joint  evaluations.  ; 

n  2 

'1 r:; 

.  I;--- 

m]  5.2:  Analyze  Cockpit  Tasks 

6.1.1;  Performance  Expectations 

6.1.2:  Estimated  Performance  J  - 
Requirements  .  v  ^ 

TT 

Tinrr 

Z]  5.3:  Design  Cockpit  Interface 

5.5:  Analyze  Controller  Tasks 

5.6:  Design  Controller  Interface 

8.2:  Summarize  Op.  Services  and  Env't 
8.3:  Perform  Safety  Analyses 

8.4:  Allocate  Safety  Objs  &  Reqs 

performance  estimates  provide  inputs  to  develop^m  of  human  factors  critefia  and  subsequent  task  analyses. 
Performance  estimates  provide  inputs  iodevelopment  of  interfaces.  Provide  inputs  to  safety  analyses. ' .  ' 

6.J,Jt  Perfornwftpp  EJipeel^tions 

6,1.2;  Estimated  Performance 
Requirements  . 

Provides  estimates  of  required  performance 

iill 

:  -  V  ' 

zm: 

f!  iS  ? 

Til 

6.2:  Define  Performance  Standards 

to  support  validation  and/or  revision  of  standards,,  i 

6.1,?!  Estimated  Performance  ■ 

IT 

_ l7.2:  Define  Ground  Svstem  Interop. 

Performance  estimates  used  as  guidance  in 

assessment  of  ground  system  interoperability. 

.6.|^|;:;:Per^rmiinpC|pf?^ 

64j|VEstimnted,Performanee;"^ 
Reqniremepts./'  '  >'.■ 

:k.: 

m3 

7.3:  Validate  Interonerabilitv 

Provides  inputs  to  support"  validation  of  interoperability  performance.  ■: 

6.1,1;  Performance  Expectations 
6,l.?f^timnted  Performance 
Requirements 

Ilf' 

1  13151  .  . 

I  _ 

8.7:  Assess  Comnarative  Safetv 

\Sysiem  performance  details  provide  background  in  addition  to  (and  potentially  revisionsmtde  after)  the  OSED, 

6.f.l;  Performance  Expectations  — 
6.1.2;  Estimated  Performnnce  . 

jyquireitiinisjiglljlllii^^^ 
Performance  estimates  provide  input  to  sco 

,1, 

J 

151  1 

1 8.8:  Formalize  Scones  of  Onerations 

ping:of  operaticm£  :- ' 

:644;;,Perfopnsnce:  Expectation^ 

6.1.?;  Estimated  Performance 
Requirements  n::;':-”:''.' ",  /;  ■ 

6.1,3;  Performance  Ram  Collection '  ^ 

Requirements,:::;v:V-i:>yi;i:l^|il|:||^|^^^ 

Provides  guidance  for  conduct  of  activity,  i 

lh 

wm 

m 

3 

TT 

n 

10.1:  Plan  Joint  Evaluations 

’)ata  collection  requirements  for  simulation  and  flight  evaluation. 

6.?,?;  Estimated  Performance 
Requirements 

Estimated  performance  requirements  are  u 

1  -rw  1 

_ 

.„L„5 

—  1.8:  Develop  Requirements  Document 

'ied  as  input  to  the  development  of  requirements. 

6,i, 2;  Estimated  Performance 
Requirements  m 

'  '■ " 

_ L 

M 

5 

“n6.3:  Develop  Ground  System  Specs 

Estimated  performance  requirements  used  > 

as  guidance  in  development  of  ground  system  specs.  ■  | 
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6.1.2:  Estimated  Performance 
Requiremenfe's?iiSpv3i; 

Per/omance  estimates  provide  basis  for  de 
stani^lffXf^&fr^dbt^Peffbrmdt^^ 
formal  avionics  standards  are  not  aVailabU 

2 

B 

9.1:  Develop  Avionics 

11.2:  Plan  and  Apply  for  Avionics  Cert. 

_ 

_ 

[3L_ 

u 

_ 

□ 

L 

velopmeniof  avionics  for  joint  evaluation  if  formal  avionics.  >f:  . 

stimates  provide  (apordortpf)  the fasis for  avionics  ^certification,  if 

6.1.2:  Estimated  Performance  kii-s-JpA-t'- 

2 

II 

W  ^rll 

1# 

■il?; 

1; 

M 

9.2:  Develop  Ground  Systems  for  Eval. 

_ 

_ 

A 

3 

_ 

_ 

_ 

3 

Estimated  performance  requirements  used  as  guidance  in  development  of  ground  system  specs.  . 
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Overview  of  Activity  6.2;  Define  Performance  Standards 

Description:  Define  and  validate  performance  standards.  In  coordination  with  RTCA,  this  provides  the 

standards  needed  for  certification.  Data  should  be  collected  throughout  simulations  and  OpEvals  and  used  to 
validate  standards.  MASPS,  which  address  overall  end-to-end  system  standards,  and  MOPS,  which  address 
avionics  standards,  will  be  developed  and/or  potentially  revised  based  on  the  validation  of  these  standards. 

Plan  and  Perform:  SC-186  POC  =  SC- 1 86  Co-chairs 

Approve  or  Accept:  SC- 186  POC  =  SC- 1 86  Co-chairs 

Products: 

6.2.1:  Revised  ADS-B  MASPS:  MASPS  provide  the  minimum  aviation  system  performance  standards  upon 
which  subsequent  end-to-end  system  designs  and  operational  applications  are  based.  ADS-B  MASPS 
provides  a  view  of  the  system-wide  operational  use  of  ADS-B,  but  does  not  describe  a  specific  technical 
implementation  or  design  architecture  to  support  the  applications.  The  revised  MASPS  is  developed  based  on 
initial  MASPS  developed  prior  to  the  application  development  process,  and  on  the  collective  results  of 
(multiple)  application  simulations  and  OpEvals  in  the  form  of  performance  estimates.  The  revised  MASPS 
also  provides  the  guiding  material  for  the  (concurrent)  generation  of  related  MOPS. 

6.2.2:  Avionics  MOPS:  MOPS  provide  the  minimum  operational  performance  standards  upon  which 
operational  avionics  and  certification  requirements  are  based.  MOPS  are  developed  based  on  MASPS  and 
other  available  data  in  the  form  of  (in  this  case)  performance  estimates.  MOPS  that  will  be  impacted  by  the 
development  and  evaluation  of  this  application  (in  concert  with  all  other  applications)  include  1090  MHz 
ADS-B,  VDL  Mode  4  ADS-B,  DAT  ADS-B,  CDTI,  and  ASSAP  (TIS-B  MOPS  will  not  be  impacted  by  this 
application,  but  will  be  by  many  of  the  other  applications). 

Issues: 

-  Methods  for  adopting  and/or  using  SARPS  and  (externally  developed)  avionics  standards  to  support  the 
establishment  of  (RTCA-approved)  standards  needs  to  be  identified 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

50 

50 

LoE  (sm) 
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1.3:  Develop  Detailed  Systems  Concepts 
6.1:  Estimate  Performance 
8.7:  Assess  Comparative  Safety 
8.8:  Formalize  Scopes  of  Operations 


1.3.1:  Detailed  Systems  Concepts 
6.1.1:  Performance  Expectations 
8.7.1:  Comparative  Safety  Analysis 
8.8.1:  AC  on  ADS-B/CDTI  Capability 
Levels  and  Lims 


Systems  concepts  support  standards  developmenty  Provides  estimates  of  required  performance  to  support 
validation  an^or  revision  of  standards.  CSA  provides  guidance  in  development  of  standards.  AC  provides  input 
to  development  of  requirements  and  standards.  '  ■  ,  ;  ^  '  u  . 


151  I  I  I  I  (6.1.2:  Estimated  Performance 
Requirements 


Provides  estintates  of  required  performance  to  support  validation  and/or  revision  of  standards.  . 


6.1:  Estimate  Performance 


Interact  with  Activi 


5.4:  Deflne  Cockpit  Interface  Stds  _  I6| . . ■ . i . , . . . .  . ll 

11.1:  Obtain  Spectrum  i .  I .  M  ‘'ijl  -1  '■! 

Cockpit  interface  standards  definition  provide  insight  into  the  definidon  of  avionfCS;f>effp^^^cii$t^^S^ds,ic0i 
vice  versa.  Definition  of  avionics  performance  statidards  and  Hie  allocMon/assigyment/pfspecdmrrifof-f^^^f''/^ 
implementation  are  performed  jointly.  ' t'  '  ■  ,  ■  ,  ■  ■  >  .  • '' 


Output  via  Product:  H  ^  H  Output  to  Activi 


6.2.1:  Revised  ADS-B  MASPS  .  _ _  '  m _  9.1:  Develop  Avionics 

6.2.2:  Avionics  MOPS  I.  I  I  I  1 6 1  I  1  1 11.2:  Plan  and  Apply  for  Avionics  Cert. 

Standards  provide  baseline  upon  which  final  avionics  designs  are  developed  -  use  if  mailable,  otherwise  use 
preliminary  designsi  Standards  provide  (portion  of)  basis  for  mionics  certification. 
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Overview  of  Activity  6.3:  Develop  Ground  System  Specs 

Description:  Translate  requirements  in  the  Requirements  Document  into  a  System  Specification  and  Interface 
Documents  that  govern  development  by  the  prime  system  /  software  contractor. 

Plan  and  Perform:  Product  Team  POC  =  PT  Lead 

Approve  or  Accept:  CCB,  With  Spec  Review  Board  POC  =  TBD 

Products: 

6.3.1:  Ground  System  Design  Specification:  This  document  translates  requirements  in  the  Requirements 
Document  into  a  specification  that  governs  ground  system  development  by  the  prime  system/software 
contractor. 

6.3.2:  Interface  Documents:  Interface  Requirements  Documents  (IRDs)  and  Interface  Control  Documents 
(ICDs)  define  each  interface  of  the  system  or  equipment  with  other  NAS  systems,  equipment,  or  facilities. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

LoE  (sm) 
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Dependencies  and  Phases: 


Input  from  Activity:  ■  HS 


1.8:  Develop  Requirements  Document 


The  FRD  is  used  to  establish  baseline  requirements. 


3.8:  Decision  -  Initial  Investment 


Post  “1  j 

flA 

Full^ 

p  Step 

Lim  -j 

p  Imp 

Dev  -1 

p  Tra 

Oon  ^  1 

It  Ins 

I  Input  via  Product: 


1.8.2:  Final  Requirements  Document 


3.8.1:  Initial  Investment  Decision 


The  Initial  Investment  Decision  initiates  the  development  of  pro^dm  plans,  r 


_ ^6.1.2:  Estimated  Performance 

I  l  \  Requirements 


Estimated  performance  requirements  used  as  guidance  in  development  of  ground  system  specs.}^: 


6.1:  Estimate  Performance 


Interact  with  Activif 


0.6:  Develop  Acquisition  Program  Plans - - - ^  -'r'" 

Development  of  ground  system  spec  and  interface  documents  may  impact  acquisition  plans,  V/ce 


Output  via  Product: 


Output  to  Activit 


^  0.7:  Prepare  Acquisition  Contract 

63.1:  Ground  System  0Mlgn  V,  :  I  I  M  I  I?!  m3.10:Decisi.n-Sel.Vendor& Award 

SpecIflcalioU  :  K!'*  ,  v  -  i  i  .-,  ,  „  „  .  .  . 

WIiIteroon-RnaUnvestment 

12.1 1 :  Develop  Maintenance  Procedures 

12.12:  Develop/Perfbrm  Maint.  Training 

Required  for  development  ofcontPachFdfmspart  of  criteria  for  vendor  selection.  Pfogam  planning  documents 
which  maintenance  ppdcMUfes  afe  based  Ground  system  specs  p}-6vidftnjmi  tqi  development  of  maintenance 

Irnininv  '  "  •'  MSte"  ‘  r""*' '  »'■  •  ■■ '  .i."' V 


training  ;  ^ 


S'f  ##  w  8.9:  Plan  Safety  foi 

7  18.10:  Analyze Haza 

6.3.1:  Ground  System  Design  — — — ^oh.a  i  u 

Specification,^^  ,, ,  .,y,  i,  .  Analyze  Haza 

6.3.2:.  Interface,  Dpctimenti^^rllMf^^^^^^  c'  '  *  ^ 

■  .1.1.1*,  ,..  i.;,,’'pi,.i., I  SUppOrt 

',)  '"V.V:,  ^v:V\:.  8.13:  Assess  Health 

Ground  system  spec  fbihns  (part  of  technical  baseline  for  implementatioh  safety  activities. 


O  pec  II  ICa  11 0  n  ,iu>  .  J 

6Xtx  thterficel)ocunientSiC^:^r":'^*'^^^  . 


8.9:  Plan  Safety  for  Implementation 
8.10:  Analyze  Hazards  of  Sub-Systems 
8.11:  Analyze  Hazards  Over-All 
8.12:  Analyze  Hazards  of  Ops  & 
Support 

8.13:  Assess  Health  Hazards 


_ LZiZJ _ J  9.3:  Manufacture  Gnd  Systems  for  Impl. 


136 


Overview  of  Activity 
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7.1:  Analyze  Interoperability 


Description:  Assess  interoperability  based  on  high-level  concepts  and  anticipated  capabilities  of  proposed 
systems,  and  develop  estimated  baseline  interoperability  requirements  for  evaluation. 

Plan  and  Perform;  Various  POC  =  TBD 

Approve  or  Accept:  Various  POC  -  TBD 

Products: 

7.1.1:  Interoperability  Asse.ssment;  This  report  provides  a  preliminary  assessment  of  interoperability  based 
on  high-level  concepts  and  the  anticipated  capabilities  of  proposed  systems,  and  baselines  estimated 
interoperability  requirements  for  subsequent  evaluations. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

■EjEH 

Tra 

Ins 

Start  Date 

Dur  (wk) 

16 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-. 
Lim  -| 

Dev  -| 

Con  -I 


Step 
n  Imp 
r-  Tra 


1.1:  Define  High-Level  Concept 

™SBSbSSBS 

1.1.1:  High-Level  Concept 

High-level  concept  provides  guidance  for  conducting  activity,  i  \ 

Interact  with  Activit 


6.1 :  Estimate  Performance  M - - — — — — — —  <  < 

*  s' 

Revisions  to  performance  estimates  provide  insight  into  analysis  of  interoperability,  and  vice  versa. 


Output  via  Product: 


Output  to  Activit 


S:  -  I  -I  I  I  I  I  I  7.2;  Define  Ground  System  Interop. 

11  I  18.2:  Summarize  Op.  Services  and  Env’t 

inieroperaDiiny  Assessmen.  ,  3. 

”  8.4:  Allocate  Safety  Objs  &  Reqs 

Provides  inputs  to  support  definition  of  ground  system  interoperability.  Provides  identification  imd  anficipated 
"  hctiondiity^and'0^fmdnci^qfis0SM-s0em'Mei§&e^^  . 


.  ■ : :.;y  l^h  ..gi  *J£47.3:  Validate  Interoperability 

9.2-.  Del^lop  cZlId  Systems  Idr  Eval. 

-  V 10.1:  Plan  Joint  Evaluations 

Provides  inputs  to  support  validation  of  interoperability  performance.  Provides  guidance  in  the  development  of 
systems  for  joint  evaluations.  Helps  identify  data  collection  heeds.  ! ; 


m 
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Overview  of  Activity 
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7.2:  Define  Ground  System  Interop. 


Description:  Identify  required  system-system  interfaces  to  support  the  anticipated  ground  infrastructure  required 
for  the  application.  These  interfaces  will  be  evaluated  and  validated  in  later  phases  of  application 
development. 

Plan  and  Perform:  OCG  POC  =  OCG  Co-chairs 

Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

7.2.1:  Estimated  Interface  Regs:  Provides  estimated  interface  requirements  to  support  the  application  in 
support  of  evaluations. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


Input  from  Activity: 


1.1:  Define  High-Level  Concept 
6.1:  Estimate  Performance 
7.1:  Analyze  Interoperability 


Post- 
Full-^ 
Lim  -1 
Dev  -I 
Con  “1 


High4evel  concept  provides  guidance  for  conducting^ 
assessment  of  ground  system  interoperability.  Provides 


-  Step 
r 

pTra 

"HTTlH  Input  via  Product: 


_  1.1.1:  High-Level  Concept 
6.1.1:  Performance  Expectations 
6.1.2:  Estimated  Performance 
B';  Requirements 

i  ?  7.1.1:  Interoperability  Assessment 


K  Performance  estimates  used  as  guidance  in . 
S  to  support  (definition  of  grovnii  system 


Interact  with  Activit' 


4.2:  Specify  Procedures  U J 

8.2:  Summarize  Op.  Services  and  Env't  P1 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 

Development  of  draft  procedures  may,  impact  jgtc 
analyses  will  impact  definition  of  ground  system' 


"i 


^bmd}syM^J0in^bperability^^^r^^ 


Output  via  Product: 


7.2.1:  Estimated  Interface  Reqs 


Output  to  Activi 


6.1:  Estimate  Performance 


Interoperability  assessrhents  provide  inputs  Jo  refinement  of  performance  estimates.  , 


. ,  i  . .  •  *  pB  -  •[  I  I  I  I  I  _ ^7.3:  Validate  Interoperabdity 

7.2.1:  Estimldted  Interliace  feeq8;^,!l<  ~  1 1 1 1  I  I  I  n 9.2:  Develop  Ground  Systems  for  Eval. 

,  ,  ■  I  10.1:  Plan  Joint  Evaluations 


Estimated  interface  requirements  used,  dsfinputto  yalidation  of  interoperability.  Estimated  interface 
requirements  used  as  guidance  irfid^etopmentpf  ^dimd  systerhs  for  evdluatioht  ' Estimated  interface  ;  •” 


^'dsi0ki!kfdsiiKiiUi^W0)'d$lu7i(!Wftf0i1ffMTiluSr0jidim.^APiffW9iiTiW0jf<fiiU9uv 
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Overview  of  Activity  7.3:  Validate  Interoperability 

Description:  Based  on  the  previous  assessment  of  interoperability  and  the  results  of  other  simulations  and 
performance  estimates,  validate  the  interoperability  performance  of  systems  supporting  the  application. 

Plan  and  Perform:  OCG  POC  =  OCG  Co-chairs 

Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

7.3.1 :  Interoperability  Validation  Report:  This  report  provides  the  results  of  the  interoperability  validation 
activity,  and  identifies  modifications  to  estimated  system  requirements,  if  necessary,  to  support  future 
implementation. 

Issues: 


-  Methods  for  adopting  and/or  using  SARPS  and  (externally  developed)  avionics  standards  to  support  the 
establishment  of  (RTCA-approved)  standards  need  to  be  identified 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

12 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-. 
Lim  -| 
Dev-| 

Con  —I 


Step 
r  Imp 
r-  Tra 


Input  from  Activity: 


6.1:  Estimate  Performance 


12  3 


_ 6.1.1:  Performance  Expectations 

—  6.1.2:  Estimated  Performance 
Requirements 


Provides  inputs  to  support  validation  of  interoperability  petformance.  ■  "  . 


7.1:  Analyze  Interoperability  X_L^J _ 7.1.1:  Interoperability  Assessment 

7.2:  Deflne  Ground  System  Interop.  . .1 ... -IBl  I  I-;.:!.;:  1“-  I  7.2.1:  Estimated  Interface  Reqs 


Provides  inputs  to  support  validation  of  interoperability  petformance.  Estimated  interface  requirements  used  as 
input tdvalidationffinterope^^^^  ■ . •  ■ 


Interact  with  Activif 


5.3:  Design  Cockpit  Interface  314  I  j  '  '■ 

5.6:  Design  Controller  Interface  ~  I  I  ,  feiCcMXu.: 

10.1:  Plan  Joint  Evaluations 

10.3:  Conduct  Joint  Evaluation  ■  1'  ' 

Interoperability  validations-^during  Joint 

versa.  Interoperability  validation  activities  Occur  in  cbnflM<Stioiimith  evalU(ffim 


7.3.1:  Interoperability  Validation  , 
Report 

pHI  f  1  1.3:  Develop  Detailed  Systems  Concepts 

|3l  1 4  1  1 6.1:  Estimate  Performance 

Assessments  of  inieroperdbility  provide  input  to  the  revisions  of  detailed  systems  concepts.  Interoperability 
assessments  provide  iHptits  to  refinement  of  petformance  estimates.  , 

7.3.i:  Interoperability  Validation  .. 

Provides  input  to  safety  assessment  dctfviti 

ptl  -  18.2:  Summarize  Op.  Services  and  Env't 

^  1  1 3  1 8.3:  Perform  Safety  Analyses 

8.4:  Allocate  Safety  Objs  &  Reqs 

9.2:  Develop  Ground  Systems  for  Eval. 
10.1:  Plan  Joint  Evaluations 

esffirpyides  guidance  in  systems  devdopment  for  evaluation.  Helps 

7.3litiEht6itbpliRability;Vaiidaii6njM^ 

Rejj^lillSilii^ 

— —  4  9.1:  Develop  Avionics 

Provides  guidance  in  avionics  development for  evaluation  &  for  Implementation.  -  5  ■  f 
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Overview  of  Activity  8.1 :  Plan  Coord.  Safety  Activities 

Description:  In  coordination  with  FAA  regulatory  authorities  and  other  FAA  and  non-FAA  stakeholders,  plan 
safety  analyses  to  guide  application  development ,  and  to  guide  implementation  decisions  for  near-term 
capability.  Detail  the  mechanisms  and  responsibilities  for  tracking  safety  hazards,  and  plan  for  safety 
representation  in  program  risk-management  activities.  Anticipate  and  document  what  further  safety  analyses, 
approvals,  and  certifications  will  be  required  to  authorize  subsequent  steps  in  the  evolution  of  the  capability. 
(Conducted  in  the  concept  phase  with  subsequent  updates  as  needed.) 

Plan  and  Perform:  TBD  POC  =  TBD 

Approve  or  Accept:  TBD  POC  =  TBD 

Products: 

8.1.1 :  Coordinated  Safety  Analysis  Plan:  Plan  the  safety  analyses  needed  for  near-term  capability.  (This 
should  be  coordinated  with  the  FAA/SEC,  and  for  capabilities  requiring  FAA  acquisition,  must  be  approved 
by  the  SEC  for  FAA  decision-making.) 

8.1.2:  Demarcations  in  Safety  Analyses.  Cert.,  and  Approval:  As  operational  capability  evolves, 
successive  increments  of  capability  will  change  in  operational  scope  (including  weather  condition,  distances, 
geometries,  airspace,  or  ATC  surveillance)  and  are  likely  to  require  changes  to  procedures  and  training  and  to 
the  functionality,  performance,  human  interface,  and  certification-level  of  avionics  and  ground  systems.  This 
product  describes  the  range  of  operational  scopes  supported  by  each  near-term  activity,  and  proposes 
demarcations  between  anticipated  future  levels  of  operational  capability  that  will  require  separate  (or 
additional)  analysis  or  validation.  (This  product  is  developed  collectively  for  multiple  applications,  and 
addresses  boundaries  both  within  and  between  them.) 

Issues: 

-  Validate  or  revise  the  safety  activities  from  this  checklist  and  specialize  them  to  create  a  detailed  plan  for 
the  safety  analyses  of  near-term  application  capabilities;  specify  details  of  what  is  to  be  done,  by  whom,  when, 
why,  and  how 

-  Evaluate  proposed  evolutions  of  capability  and  identify  additional  analyses,  approvals,  and  certification 
needed  to  support  successive  levels  of  capability;  coordinate  with  stakeholders  on  specific  safety  requirements  for 
alternative  evolution  strategies 

-  Evolution  plans  may  not  be  sufficiently  defined  for  timely  assessment  of  safety  constraints 
Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 
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Ins 

Start  Date 

Dur  (wk) 

8 
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Dependencies  and  Phases: 


Post  ^  r—  lA 


Input  from  Activity: 


1.1:  Define  High-Level  Concept 
1.6:  Develop  Research  Evaluation  Plan 


Input  via  Product; 


1.1.1:  High-Level  Concept 
1.6.1:  Research  Evaluation  Plan 


High-level  concept  provides  guidance  for  conducting  activity.  The  REF  identifies  issues  that  need  to  be  , , . 
addressed.  :  in:-'":-'"''''’''" ' ' 


Interact  with  Activity: 


0.1:  Develop  and  Revise  SF21  MP 
0.2:  Develop  and  Revise  Checklist 
0.3:  Manage  Issues  and  Risks 
0.4:  Administer  SF21  Program 
4.1:  Plan  Procedure  Development 
5.1:  Plan  Human  Factors  Activities 


. 


' ;  'V' 

'  5  ^  J'sVN"  ■,  s'm  5  >"!  ,‘"1^  ir'J’ 

,  , ^  L , ,  V  iir !’ '' r  r‘; 

rl^  .  '1;::  1F  '  < 


I  -  - — -  . — » i  ll’  Tv’* "  ,  -  '  ^  ,  *> 

Provides  insight  into  refinement  of  interacting  activity  products  and  VtceversaS^t^fdentifycnaHgesMeMded 


(and  vice  yersafi Improved mderstandihg df'H^ffsuh  witlcldrijy  theareasM^^J^^0!^^y^^ 
[previewing  sctfety  issues  in  drafting  the  HFplanMiU  Influeti^e  fhe  sh’ate^fok  a^^  developtnent.  ■ 


Output  via  Product; 


8.1.1:  Coordinuted  Safety  Ainslysis  t*Ian 


Output  to  Activity: 


8.2:  Summarize  Op.  Services  and  Env't 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 


Coordinated  Safety  Activities  Plari  Will  guide  safety  analyses.  : 

8.1.1:  Cdordliiated  Safety  Analysis  iPlkd 

■  4'  1.  '  ’  '  ,*«  1  [Ml 


y  1 

□ 

m 

i|i 

1 

. J 

8.5:  Track  Safety  Issues  During  Dev't 


Plans  the  process  for  sdfe^  activities,  including  Cpprdination^Qn  issues: 

8.E:l|Cod|d{^|i;:^ 


8.6:  Ensure  Safety  of  Testing 


analyses., 


in 

■ 

■■ 

■ 

i 

E 

□ 

m 

|i|  ! 

□ 

1 

8.1.1;pob|bdiddte4  jafety^AiialysIsj^fen 


■H8.7:  Assess  Comparative  Safety 


Coordinated  '.^dMWX'etMties  Pldh'Mlt  ^ide, safety  analyses. 


8.1.1:  Coordinated  Safety  Analvsfa  Pian  111* 
8.1.2:  pemai'catlonsP  Safely  Analyses,  [ZL 
Cert.,  and  Approvai''  ' 


CoordiHated  Safety  Activities  Plan  will  guide  safety  analyses,\  The  demarcations  between  applications  for  safety 
analysis,  certification,faTid  dpproyal  wiliM  Wl^^  Os  On  AC  byAFSin  consultation  with  AIR. 


1 8.8:  Formalize  Scopes  of  Operations 


5 


8.1.1:'Cbdlrdittdted'!Sfieity.Anaiyl’' 


E 


8.9:  Plan  Safety  for  Implementation 


Coordinated  Safety  Activities  Plan  will  guide  safety  analysesi  :  . 
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Overview  of  Activity  8.2:  Summarize  Op.  Services  and  Env't 

Description:  Insure  that  systems,  operations,  and  environment  for  near-term  applications  capability  are 
adequately  defined.  Draw  on  or  reference  ops-concepts,  draft  procedures,  system  definitions,  and 
performance  information  to  summarize  anticipated  application  parameters  that  are  relevant  to  safety  so  they 
can  be  used  in  analyses  to  guide  further  development  of  the  application.  This  activity  is  iterative,  using 
available  documentation  while  working  with  on-going  efforts  defining  operations,  procedures,  systems, 
interfaces,  and  performance  expectations. 

(See  RTCA  DO-264  and  the  FAA  System  Safety  Management  Plan  and  System  Safety  Handbook). 

This  activity  is  conducted  in  the  Concept  phase  with  revisions  in  the  Development,  Limited,  and  OpEval 
phases. 

Plan  and  Perform:  TBD  POC  =  TBD 

Approve  or  Accept:  TBD  POC  =  TBD 

Products: 

8.2.1:  Operational  Services  and  Env't  Definition:  This  should  include  type  of  airspace,  equipage  levels, 
weather  limitations,  distances  and  geometries,  user- interface  functionality,  workload  considerations,  user 
training,  secondary  systems,  procedural  confirmations,  fallback  procedures,  and  system  characteristics. 

Issues: 

-  Summarize  airspace  users  operational  objectives,  ATS  providers  Intentions,  and  intended  operational 
capabilities 

-  Summarize  the  air  traffic  services  provided  by  the  CNS/ATM  system 

-  Summarize  system  functional  characteristics,  performance  expectations,  and  technologies 

-  Identify  dependencies  on  aircraft  equipage  or  ATS  provider  technical  system  automation,  including  ATS, 
procedural  requirements,  operational  scenarios,  and  human  factors  requirements 

-  The  operational  environment  for  which  the  services  are  intended  include  separation  minima,  route 
configuration  and  complexity,  type  of  ATM  services,  airspace  class,  traffic  characteristics,  traffic  rates,  and 
aircraft  mix 

-  (Updates)  The  OSED  is  updated  with  information  resulting  from  development,  evaluation,  and  safety 
analyses  (it  is  not  used  after  formal  standards  and  requirements  are  defined) 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 
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Start  Date 

Dur  (wk) 

4 

4 

4 

4 
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Dependencies  and  Phases: 


Post- 
Full-| 
Lim  -1 
Dev-| 

Con  —1  I 


Step 
r  Imp 
I-  Tra 


Input  from  Activity: 


1.1:  Define  High-Level  Concept 
1.6:  Develop  Research  Evaluation  Plan 
7.1:  Analyze  Interoperability 


Input  via  Product: 


1.1.1:  High-Level  Concept 
1.6.1:  Research  Evaluation  Plan 
7.1.1:  Interoperability  Assessment 


Hi^hrleyd  concept  provides  ^idmeeJbr^^m^in^i^iU^t^'SwjREPJdenttfl^s  'issues.ithatmeM-tO'beA:pV^^^^ 
addressed.  Provides  identification  arid  anticipated flmcttdn^ify  and  perforthdrtc^pf  system‘S0^pi  inteTfaces.^_^ 


1.2:  Develop  Detailed  Ops  Concepts  2 1 3  |  J _ 1.2.1:  Detailed  OPS  Concepts 

1.3:  Develop  Detailed  Systems  Concepts  I  1.3.1:  Detailed  Systems  Concepts 


Provides  guidance  for  conduct  ofactmty.  Validates  and  provides  informal  information  sharing  in 


6.1:  Estimate  Performance 


Provide  inputs  to  safety  analyses,  :  : 


7.3:  Validate  Interoperability 


Provides  input  to  safety  assessment  activities,  ;  :  i  '  : 


8.1:  Plan  Coord.  Safety  Activities 


Coordinated  Safety  Activities  Plan  will  guide  safety  analyses. 


6.1.1:  Performance  Expectations 
6.1.2:  Estimated  Performance 
Requirements 


7.3.1:  Interoperability  Validation 
Report 


8.1.1:  Coordinated  Safety  Analysis  Plan 


Interact  with  Activif 


4.2:  Specify  Procedures 
5.2:  Analyze  Cockpit  Tasks 
5.3:  Design  Cockpit  Interface 
5.5:  Analyze  Controller  Tasks 
5.6:  Design  Controller  Interface 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 
8.5:  Track  Safety  Issues  During  DevT 


1I2I3I4 

||2iU 


considerations  influence  task  analyses  dhd^jiceyersdlMitidl^tMM'^^^ 


7.2:  Define  Ground  System  Interop. 


Safety  analyses  will  impact  definition  q 


8.6 

10. 
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Safety  considerations  cmd  the  need for  safety~relevant  specifics  will  influence  the  specification  of  the  applications 
concept,  both  for  systems  and  operations^’ '  "  ■  '  ,  '  -y?  , .  .  ■ 


Output  via  Product: 


8.2"l5  Operational  Services  and  Env't 
Definition''"' 


Output  to  Activity: 


1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 
6.1:  Estimate  Performance 


8.2.1:  Operational  Services  and  Env't 
Definition  "  j 

Results  of  activities  aid  in  the  development  of  requirements  documents. 


mmmm 

Ip 

jior 

n 

11 

i 

W| _ 

- 1 

- i 

TT 

_ 

□ 

—  1.8:  Develop  Requirements  Document 

"  ''vfs, .!  '{i-  ‘ 


1314 


8.7:  Assess  Comparative  Safety 


8.24  s  Operational  Services  and  Env't 

PeQnitiph::"':;'^  _ 

The  OSED  defines  the  (new)  alternative  andiis  context  for  comparison  to  current  operations  attd  systemsf" 


8.24;  Operational  Services  and  Env't 
Dellaition  ! 


Results  of  activities  aid  in  the  development  of  operational  scopes. 


"TT 

— 

1  |4 

8.8:  Formalize  Scopes  of  Operations 


ifipi 

g 

1 

“m 

4] 

8.2.1;  Operational  ServiPfs  and  Env't. 
Deflnition 


8.9:  Plan  Safety  for  Implementation 
8.10:  Analyze  Hazards  of  Sub-Systems 
8.11:  Analyze  Hazards  Over- All 
8.12:  Analyze  Hazards  of  Ops  & 
Support 

8.13:  Assess  Health  Hazards 


8.2?};  Operational  Services  and  Env't 


\m 


1 11.2:  Plan  and  Apply  for  Avionics  Cert. 
1 11.3:  Estab.  Avionics  Cert.  Project 
12.2:  Request  Operational  Approval 
(Ph.2) 

12.3:  Review  Application  Package  (Ph. 

3) 


Safety  analyses  provide  a  starting  point for  the  certification  process  ( und  provides,  background  for  the  cert, 
project).  Safety  analyses  provide  inputs  to  the  approval  process! '  i 
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Overview  of  Activity  8-3:  Perform  Safety  Analyses 

Description:  Based  on  the  evolving  OSED,  iteratively  analyze  safety  implications  of  the  capability.  Provide 
qualitative  and  quantitative  guidance  that  will  enable  safety  objectives  and  requirements  to  be  defined, 
refined,  and  allocated.  With  each  iteration,  use  the  increased  specificity  in  the  OSED  to  conduct  more 
detailed  and  quantitative  analysis.  The  initial  iteration  will  be  an  Operational  Hazard  Assessment  (OHA)  in 
the  concept/development  phase.  Begin  with  functional  analysis  of  the  application  to  derive  a  preliminary 
hazard  list.  Next,  identify  contributing  hazards,  initiators,  and  other  causes.  Baseline  any  controls  for  these 
that  are  in  the  current  OSED,  and  list  potential  outcomes,  harms,  and  hazard  effects.  Determine  the  worst 
credible  severity  of  consequences  for  each  hazard  in  consideration  of  the  baselined  controls,  and  from  this, 
propose  target  levels  of  safety  for  important  hazards.  If  needed,  propose  new  restrictions  on  the  environment 
of  operation. 

Iterations  in  the  limited-  and  full-evaluation  phases  will  be  Preliminary  Hazard  Analyses  (PHA),  or  if 
sufficient  information  exists,  Subsystem  and  System  Hazard  Analyses  (SSHA  and  SHA)  that  extend  the 
OHA.  Update  the  hazard  list  and  analyze  hazard  severity  using  new  specifics  and  controls.  Analyze  the 
probability  of  severe  consequence  including  the  new  control  baseline,  and  code  and  rank  the  resulting  risks 
for  use  in  hazard  tracking  and  program  risk  management. 

(See  FAA  Safety  Handbook  chapters  8&9,  and  FAA  SSMP  sections  5.3.4,  6,  &7.) 

Plan  and  Perform:  TBD  POC  =  TBD 

Approve  or  Accept:  XBD  POC  =  TBD 

Products: 

8.3.1:  Operational  Hazard  Assessment: 

8.3.2:  Hazard  Analysis  (PHA  or  SSHA/SHAl: 

Issues: 

-  Perform  or  update  (or  if  available,  validate)  functional  analysis  of  the  capability  as  described  the  OSED 

-  List  or  update  Operational  Hazards;  identify  or  update  contributory  hazards,  initiators,  and  other  causes; 
establish  or  update  a  hazard  control  baseline  based  on  the  OSED 

-  Identify  or  update  relationships  between  system  failures,  procedural  errors,  and  combinations  of  these  that 
contribute  to  hazards;  identify  or  update  the  effect  of  controls  on  these  relationships 

-  Assess  or  analyze  and  update  the  severity  of  potential  outcomes,  effects,  or  harm  considering  baselined 
controls  (prior  to  full  evaluation  and  CHA:  if  a  control  is  believed  likely  to  be  reconsidered  (in  ASOR  or  in 
subsequent  development  or  evaluation),  determine  severities  with  and  without  the  control  in  order  to  guide 
potential  trade-offs) 

-  In  limited  or  full  evaluation  phases,  analyze  the  probability  of  severe  hazards  and  assign  risk  codes 

-  Rank  hazards  (by  risk  if  known);  propose  target  levels  of  safety  for  identified  hazards,  and  if  needed, 
recommend  additional  limits  on  the  environment  of  operation 

-  Provide  to  ASOR  and  risk  management:  controls  baseline,  hazard  ranking  (risk  ranking  with  risk  codes  if 
available),  recommended  target  levels  of  safety,  and  recommended  additional  limits  on  environment 


Schedule: 
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4 

4 
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Dependencies  and  Phases: 


Dev 

Con 


Innut  from  Activity: 


1.1:  Define  High-Level  Concept  111 

1.6:  Develop  Research  Evaluation  Plan  P* 
7.1 :  Analyze  Interoperability 

High-level  concept  provides  guidance  for  condm 
addressed.  Provides  identification  and  anticipate 


1.2:  Develop  Detailed  Ops  Concepts  I  I 
1.3:  Develop  Detailed  Systems  Concepts 


Prdvides  guidance  for  conduct  of  activity.  ' 


6.1:  Estimate  Performance 


Provide  inputs  to  safety  analyses 


7.3:  Validate  Interoperability 


Provides  input  to  safety  assessment  activities. "  • 


8.1:  Plan  Coord.  Safety  Activities 


2  3 


_ Input  via  Product: _ 


I _ 1.1.1:  High-Level  Concept 

*3-2-  L6.1:  Research  Evaluation  Plan 
7.1.1:  Interoperability  Assessment 

The  REP  identifies  issues  that  need  to  hci'  :  . 
y  and  performance  of  system-system  interfaces. 


1 1.2.1:  Detailed  OPS  Concepts 
1.3.1:  Detailed  Systems  Concepts 


6.1.1:  Performance  Expectations 
6.1.2:  Estimated  Performance 
Requirements 


7.3.1:  Interoperability  Validation 
Report 


8.1.1:  Coordinated  Safety  Analysis  Plan 


Interact  with  Activi 


4.2:  Specify  Procedures 
5.2:  Analyze  Cockpit  Tasks 
5.3:  Design  Cockpit  Interface 
5.5:  Analyze  Controller  Tasks 
5.6:  Design  Controller  Interface 
8.2:  Summarize  Op.  Services  and  Env't 
8.4:  Allocate  Safety  Objs  &  Reqs 
8.5:  Track  Safety  Issues  During  Dev't 


■J'll 


!  V;  f 


Vice  versa 


considerations  influence  task  analyses  (W  vice  versa  Initially  and  as  they  are  updated,  the  OSEB'fitpy^td?^, 
information  to  safety  analysis  and  ASOR  analyses  ofhqzards  identifies  gap's  in  the  OSED  <md  guid^MSOl^  md 
ASOR  specifies  and  allocates  needs  identified  in  safety  analysis  to  elements  of  the  capability  described, ip  the 
OSED^  Issues  arising  from  or  resolved  by  analysis  are  communicated  with  other  development  and  evaluation  1  ' , 
activities.  '  ■  ■ .  3;:rvv;:, 


7.2:  Define  Ground  System  Interop. 


Safety  analyses  will  impact  defi 


8.6:  Ensure  Safety  of  Testing  I 

10.1:  Plan  Joint  Evaluations 


Safety  considerations  influence  testing  and  vice  versa 
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Output  via  Product: 


8.3.1:  Operational  Hazard  Assessment 
8.3.2:  Hazard  Analysis  (PHA  or  V  ' 

SSHA/SHA):l|:;i's;gS|||p| 


Output  to  Activity: _ 


1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 
6.1:  Estimate  Performance 


Safety  considerations  and  themed for  safety-relevant  specifics  mil  influence  the  specification  of  the.  applications 
concept;  bothfbr 


8.3.1:;:Operational  Hazard  Assessment ,  El  1  I  I  I 

8.3.2:  Hazard  Analysis  (PHA  or  I  I  I  I  4|  |  1 1.8:  Develop  Requirements  Document 

_ _ _ _ _ _ 

Results  of  activities  aid  in  the  development  of  requirements  documents.  \  .  k:-; 


8.3.1:  Operational  Hazard  Assessment  i  •  i  I 

8.3.2:  Hazard  Analysis  (PHA'o'r' '"'W':',  I  |3|4|  |  |  [ j Js.7:  Assess  Comparative  Safety 

SSHAJf|0||||ij||j^^  _ 

The  OSED,  safety  analyses,  and  ASOR  from  the  R&D phases  provide  data  and  analysis  on  the  new  capability  to 
start  comparative  safety  analyses  that  support  commitment  decisions.  '  '  '  _ '  ' ' 


8.3.1:  Operational  Hazard  Assessment  ■  -  '‘■.M  - 1 I '  r'-' 

8.3.2:  Hazard  Analysis  (PHA  or  .  1.1 [  _ L [ LJ  8.8:  Formalize  Scopes  of  Operations 


8.3.2:  Hazard  Analysis  (PHA  or  '  .1 . 1  I  Kl  I  I . 

Results  of  activities  aid  in  the  development  of  opefdtional  scopes. 


8.9:  Plan  Safety  for  Implementation 

“"r  n  4  n 

8.10:  Analyze  Hazards  of  Sub-Systems 

8.3.1:  Operational  Hazdrd  Assessment 

8.3.12:  Hazard  Analysis  (PtiA  or  ,  , 

SSH^SHAlj-ililllg 

8.11:  Analyze  Hazards  Over- All 

8.12:  Analyze  Hazards  of  Ops  & 

Support 

8.13:  Assess  Health  Hazards 

RepdrtS:ufrd''m:ihpidjdfrrflemeifrSldnJqfrty^ctiyitiesiM^^MM&i:±SfrMm$;0fWtiS^frpfr^ 

2vlEI  1' 

11.2:  Plan  and  Apply  for  Avionics  Cert. 

11.3:  Estab.  Avionics  Cert.  Project 

8.3.1:  Operational  Hazard  Assessment 

8.3.2:  Hazard  Analysis  (PEtA  6r  "1 

12.2:  Request  Operational  Approval 
(Ph.  2) 

12.3:  Review  Application  Package  (Ph. 

3) 

Safety  analyses  provide  a  starting  point  for  the  certification  process  f 
project)!  Safety  analyses  provide  inputs  to  the  approval  process. 

and  provides  background  for  the  cerp. 
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8.4:  Allocate  Safety  Objs  4&  Reqs 


Description:  Based  on  target  levels  of  safety  and  system/procedure  failure  relationships,  Allocate  Safety 
Objectiives  and  Requirements  (ASOR)  to  elements  of  the  capability  as  they  are  called  out  in  the  OSED  or 
derived  by  functional  analysis.  Allocation  must  be  negotiated/coordinated  with  stakeholders  and  their 
technical  representatives.  (See  RTCA  D)-264.) 

Changes  to  baselined  hazard  controls  will  require  modification  of  the  OSED  and  updates  to  safety  analyses, 
which  may  feed  back  via  revised  target  levels  of  safety  or  new  limits  on  environments  for  operation.  ASOR 
is  performed  in  the  context  of  techical  performance,  interoperability,  and  cost/benefit-based  requirements, 
which  must  be  considered  simultaneously,  but  may  be  documented  or  revised  in  other  or  subsequent 
activities. 


Plan  and  Perform:  TBD 


POC  =  TBD 


Approve  or  Accept:  TBD 


POC  =  TBD 


Products: 

8.4.1:  ASOR: 


Issues: 

-  Evaluate  target  levels  of  safety  and  system  procedure  failure  relationships  to  understand  trade-offs  in 
ASOR 

-  Negotiate  and  coordinate  alternative  allocations  of  requirements  with  stakeholders 

-  Coordinate  any  shared  safety  objectives  and  requirements  across  organizational  boundaries 

-  Identify  any  unresolved  requirements  for  program  risk  management 

-  Provide  working  specifications  and  requirements  for  R&D  use  until  formal  standards  and  specifications  are 
available 

-  Identify  any  changes  (or  potential  changes)  to  the  hazard  control  baseline  for  incorporation  into  the  OSED 
and  safety  analyses 

Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

4 

4 

4 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


F 

Lim 
Dev 
Con 


Input  from  Activity: 


1.1:  Define  High-Level  Concept 
7.1:  Analyze  Interoperability 


Input  via  Product: 


1.1.1:  High-Level  Concept 
7.1.1:  Interoperability  Assessment 


High-level  conceptprovides  guidance  for  conducHrig^'a^^^  Provides  identification  and  anticipated 
imctiOfiBiiy-'drid 


1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 


Provides  guidance  for  conduct  of  activity. 


6.1:  Estimate  Performance 


Provide  inputs  to  safety  analyses.  ^ 


7.3:  Validate  Interoperability 

Provides  input  to  safety  assessment  activities.  ” '  < " 


8.1:  Plan  Coord.  Safety  Activities 


Coordinated  Safety  Activities  Plan  mil  guide  scfefy  tmdlysesrf 


1.2.1:  Detailed  OPS  Concepts 
1.3.1:  Detailed  Systems  Concepts 


6.1.1:  Performance  Expectations 
6.1.2:  Estimated  Performance 
Requirements 


7.3.1:  Interoperability  Validation 
Report 


8.1.1:  Coordinated  Safety  Analysis  Plan 


Interact  with  Activit 


4,2:  Specify  Procedures 

5.2:  Analyze  Cockpit  Tasks 

5.3:  Design  Cockpit  Interface 

5.5:  Analyze  Controller  Tasks 

5.6:  Design  Controller  Interface 

8.2:  Summarize  Op,  Services  and  Env’t 

8.3:  Perform  Safety  Analyses 

8.5:  Track  Safety  Issues  During  Dev’t 


1I2I3I4 

iifin 


"Will 


considerations  influenc&  iask  analyses  ahd^i^sa.  tnilially  and  ds 
information  to  safety  fmaly sis 

ASOR  specifies  and  allocates  needs  identified  in  kWety  mdlysis  to  elements  bf  the  capabitiH  deScrJbed  in  the 
OSED.  Issues]  arisingfrom  or  resolyed  by  d^myM^i^ofkmMpiated  Wth^ 


8.6:  Ensure  Safety  of  Testing 
10,1:  Plan  Joint  Evaluations 


rnrni^smmmm 
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Output  via  Product; 


8.4.  J:  ASOR 


Output  to  Activity; 


1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 
6.1:  Estimate  Performance 


Safety  considerations  and  the  need for  safety-relev<mt  specifics  will  influence  the  specification  of  the  applications 

8.4.1:  ASOR 


H 


1.8:  Develop  Requirements  Document 


Results  of  activities  aid  in  the  development  of  reggirementidocuments. 


8.4.1;  ASOR 


31 4 


8.7:  Assess  Comparative  Safety 


Fault-trees  will  be  incorporated  into  severity  mdlysisfor  pqmparisom  -allocations  wUl  be  assumed  for 


8.4,1?  ASOR 


m 

Hlg 

■  411 

■ 

■1 

H 

■■11 

■ 

■ 

1 

M 

' y 

N 

□ 


8.8:  Formalize  Scopes  of  Operations 


8.4.1;  ASOR 


..  '1,  ,1  -J  <1-: 


8.9:  Plan  Safety  for  Implementation 
8.10:  Analyze  Hazards  of  Sub-Systems 
8.11:  Analyze  Hazards  Over- All 
8.12:  Analyze  Hazards  of  Ops  & 
Support 

8.13:  Assess  Health  Hazards 


Reports  used  as  input  to  implementation  safety  activities. 


. 

. 


2  3 


11.2:  Plan  and  Apply  for  Avionics  Cert. 
1 11.3:  Estab.  Avionics  Cert.  Project 
12.2:  Request  Operational  Approval 
(Ph.  2) 

12.3:  Review  Application  Package  (Ph. 
3) 


Sqfety  analyses  provide  a 
project).  Safety  analyses  provide  inputs  to  the  approval  process. 


cert. 
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Overview  of  Activity  8.5:  Track  Safety  Issues  During  Dev’t 

Description:  Participate  in  program-level  risk  management  activities  to  insure  that  safety-relevant  concerns  are 
communicated  between  safety  analysts,  application  developers,  program  planners,  managers,  and 
stakeholders.  Insure  that  safety-relevant  issues  and  resolutions  are  tracked  and  documented.  Insure  that  valid 
safety  information  is  available  during  coordination  for  decision-making. 

This  activity  is  conducted  in  All  phases. 


Plan  and  Perform:  TBD 

POC  =  TBD 

Approve  or  Accept:  TBD 

POC  =  TBD 

Products: 

8,5.1:  Safety  Issues  and  Resolutions: 


Schedule: 


Con 

Dev 

LIm 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

999 

999 

999 

999 

24 

LoE  (sm) 
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Dependencies  and  Phases: 


Post- 
Full-| 
Urn  -| 
Dev-i 
Con  -I 


Step 
p  Imp 
i-Tra 


Input  from  Activity: 


Input  via  Product: 


I II  i '  1 M  n 


8.1:  Plan  Coord.  Safety  Activities 


Plans  the  process  for  safety  activities,  including  coordination  on  issues/^%  v 


Interact  with  Activi 


8.1.1:  Coordinated  Safety  Analysis  Plan 


8.6:  Ensure  Safety  of  Testing 
10.1:  Plan  Joint  Evaluations 
11.3:  Estab.  Avionics  Cert.  Project 
12.3:  Review  Application  Package  (Ph.  I  ■ 

_ _ _ I 

Issues  are  coordinated  with  program  management  and  other  activitiesf''W.^^~i-’~'^ 


5 


8.8:  Formalize  Scopes  of  Operations 


Issues  arising  from  or  resolved  by  analyses  arf  fom^icgiedwith  evaluation  actMdfS  m 
management, ;  ^ 


Output  via  Product: 


Outnut  to  Activi 


8.5.1?  Safety  Issues  und  Resolutions  |  |2^"'F^  I  1  T  I  I  *®‘’  Decisions 

ffM&sf^utsWF^frecMonfrakingfriWm&S^^i^lt^^  -  - "■ 

8.5,1?  Safety  Issues  and  Resolutions  5r  r - Z^Z___E-_  i.g;  Develop  Requirements  Documer 

^stilts  ^(uctivities  aid  in  the  development  of  requirements  documents,  ■  ~  v  ?  ■ 

8,5,1:  Sufety  Issues  qnd  Resolutions  — -Ip~^  j  — — — jg.O:  Plan  Safety  for  Implementation 

Safety  issues  used  as  input  to  planning  safety  for  implementation.  :  _ ’ 


1.8:  Develop  Requirements  Document 


.  . . '  M  ■ _ _  1 11.3:  Estab.  Avionics  Cert.  Project 

8.5,1:  Safety  Issues  and  Resolutions  I  I  i  l  J  1 12.3:  Review  Application  Package  (Ph. 

Safety  issues  provide  partial  basis  for  certification  issues  and  resolutionsfrocument.  ; -i 
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Overview  of  Activity 
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8.6:  Ensure  Safety  of  Testing 


Description;  Perform  analyses  and  assessments  as  appropriate  to  identify  potential  safety  issues  in  conducting 
operational  tests.  Develop  strategies  to  insure  test  safety.  Coordinate  within  field-evaluation  planning-teams 
to  facilitate  resolution  of  issues  and  confirm  safe  practices.  Provide  status  assessments  on  test  safety  to 
evaluation  managers  and  program  managers  and  regulatory  authorities  as  appropriate.  Insure  that  appropriate 
documentation  of  safety  strategies  is  available  for  incorporation  in  Test  and  Evaluation  Master  Plans.  Insure 
that  appropriate  documentation  of  safety  preparations  and  of  the  safe  conduct  of  testing  are  available  for 
OpEval  Final  Reports. 

This  activity  is  conducted  in  the  Limited  and  Full  Evaluation  Phases 


Plan  and  Perform:  TBD 

POC  =  TBD 

Approve  or  Accept:  TBD 

POC  =  TBD 

Products: 

8.6.1:  Test  Safety  Strategy: 
8.6.2:  Test  Safety  Review: 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

4 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


Innut  from  Activity: 


4.2:  Specify  Procedures 
5.2:  Analyze  Cockpit  Tasks 
5.5:  Analyze  Controller  Tasks 


Post- 

Full-, 

Urn 

Dev-| 

Con  -I 


Step 
r  Imp 
.-Tra 


I _ Input  via  Product; _ 


4.2.1:  Procedures  Specification 
5.2.1:  Cockpit  Task  Analysis  Report 
5.5.1:  Controller  Task  Analysis  Report 


Brmides  infarmcUion  on  expectations,  requirements,  operational  semitivUies  &  mitigations: 


8.1:  Plan  Coord.  Safety  Activities 


Coordinated  Safety  Activities  Plan  will  guide  safety  mcdys^s* 


8.1.1:  Coordinated  Safety  Analysis  Plan 


Interact  with  Activi 


0.3:  Manage  Issues  and  Risks 
4.5:  Train  for  Procedures 
8.2:  Summarize  Op.  Services  and  Env’t 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 
8.5:  Track  Safety  Issues  During  Dev’t 
9.2:  Develop  Ground  Systems  for  Eval. 
10.1:  Plan  Joint  Evaluations 


•  '  'i  /  "J!") 'if :  s  ^  J  -7  . 


^  K.-  ^  ^  S'  ^  ''' 

-  '■ '  'f %r:?' r'  ' ' 


Incorporates  safety  and  other  issues  into  sqfetydfrafegyfor  tes.tin§£Sa^e^^fgcfegi^s^^H^ied  at  the  ti^e 
training  materials  are  developed  will  be  incl^e^  in  the  materials  '^rf^&^et^str0^esy^iUbe^o^orc^^ 
into  participants  training  and prepemation  arejefined,)  Safkty  cqneider^iomirfluence  iestmg^hf  ' 

versa  Issues  are  coordinated  with  program  management  and  other  activUie^Xest  safety  will  irppact 
development  of  gromd  systems  for  evaluation  ani^  yersa:.$afefy  malfj^MH  in^^t  plamingfor  f;  tf 

evaluations.  ’■  ■  i'S  7  ■■■  :: 


Output  via  Product: 


Test  Safety, Strategy  '■ , - 10, 

Test  safety  strategy  used  as  guidance  in  conduct  of  joint  evaluatiormi¥¥& 


8.64:'.Test  Safety  Review  ••••  -  |—  ""^^  4  " — — " — “  0-* 

provides  inputs 'io'TJAfdecision  mdkingMfsMiSm^ 


Output  to  Activi 


10.3:  Conduct  Joint  Evaluation 


0.5:  Coordinate  for  Decisions 
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Overview  of  Activity  8.7:  Assess  Comparative  Safety 

Description:  A  Comparative  Safety  Assessment  (CSA)  assesses  the  severity  and  likelihood  of  application 
hazards  relative  to  the  severity  and  likelihood  of  hazards  in  baseline  systems  and  operations.  Whereas  the 
OSA  is  structured  to  guide  application  development  toward  target  levels  of  safety,  the  CSA  is  structured  to 
validate  the  relative  safety  of  the  application  and  guide  decisions  on  whether  it  should  be  implemented. 

(See  FAA  System  Safety  Handbook,  Chapter  4,  Section  4.2  dated  8/2/00). 

This  activity  occurs  in  the  Full  Evaluation  Phase. 

Plan  and  Perform:  TBD  POC  =  TBD 

Approve  or  Accept:  TBD  POC  =  TBD 

Products: 

8.7.1;  Comparative  Safety  Analysis:  The  CSA  is  a  risk  assessment  that  defines  both  severity  and  likelihood 
in  terms  of  the  current  risk  of  the  system  alternatives.  A  risk  assessment  provides  an  estimation  of  the  risk 
associated  with  the  identified  hazards. 

8.7.2:  Comparative  Hazard  Probs  in  Worst  Cred.  Conds: 


Schedule; 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

start  Date 

Dur  (wk) 

12 

12 

LoE  (sm) 
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Dependencies  and  Phases: 


Post- 
Full-. 
Urn  -1 
Dev-, 

Con  -1 


Step 
r  Imp 
i-Tra 


1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 
6.1:  Estimate  Performance 


1.2.1:  Detailed  OPS  Concepts 
1.3.1:  Detailed  Systems  Concepts 
6.1.1:  Performance  Expectations 
6.1.2:  Estimated  Performance 
Requirements 


% 


8.1.1:  Coordinated  Safety  Analysis  Plan 


Coordinated safety  analyses. _ ■  -'r  _ • 


3  14 1  I _ 8.2.1:  Operational  Services  and  Env't 

.  ^  .  .  T,  .  ''  *-'l'  'I  -  Definition 

8.2:  Summarize  Op.  Services  and  Env  t  •  ;  ;  ^  g  3  j.  Operational  Hazard  Assessment 

8.3:  Perform  Safety  Analyses  8.3.2:  Hazard  Analysis  (PHA  or 

8.4:  Allocate  Safety  Objs  &  Reqs  U  SSHA/SHA) 

8.4.1:  ASOR 

TheOSED  defines  the  (new)  alternative  and  Us  context  for  comparison  to  current  operations  and  systems.  The 
OSfip^  safety  analyses^  andASOE  from  the  fipD  phases  provide  data  and  analysis  on  the  new  capability  to  start 
'cS]0Kitiv^safpyomadv^iSi^-siS&cdwm&S0fWSMdmlmn^rf^Esfi^^  ’ 

analysis  for  comparisons  •  allocations  will  be  assumed for  comparative  analysis.  ’’  _ ~ 


8.1:  Plan  Coord.  Safety  Activities 


Interact  with  Activi 


8.5:  Track  Safety  Issues  During  Dev't  L  j  V-.'??-.  v  ' " 

Issues  arising  from  or  resolved  by  analyses  gre  coptmunicated  with  evaluation  activities  andpyo^am  .  • 

management.  ■ '  ■  (  ■' ■  '''■ 


Output  via  Product: 


8.7,|.;  Comparative  §afety  Analysis 


Output  to  Activitv: 


!  0.5:  Coordinate  for  Decisions 


of EusinessKincluding  regulatory  authorities)  on  relatiye  safety,  and  oo  residual 


Provide  guidance  to  FAA  lines  of  business  (including  regulatory  a 
issues  that  should  be  monitored  to  ensure  safety  benefits.  ■' 


8.7,1;  Comparative  Safety  Analysis  '  '  _J _ I _ ^ _ I _ [iJ _ ^ _ 

CS4  results  are  used  as  inputs  to  the  fieyelopjncnt  of  requirements 
development  of  staridar^.  --T  , 


8.7.1:  Comparative  Safety  Analysis 
8.7,?j  Comparative  Hazard  Probs  in  ■ 

Worst  Cred.Conds 

CSA  results  used  as  input  to  implementation  safety  activities^ 


I  1 1.8:  Develop  Requirements  Document 
I  1 5.4:  Define  Cockpit  Interface  Stds 
6.2:  Define  Performance  Standards 

documents.  CSA  provides  guidance  in 


p  8.9:  Plan  Safety  for  Implementation 
1  1 8.10:  Analyze  Hazards  of  Sub-Systems 
8.11:  Analyze  Hazards  Over- All 
8.12:  Analyze  Hazards  of  Ops  & 
Support 

8.13:  Assess  Health  Hazards 
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8.7.1:  Comparative  Safety  Analysis 

8.7.2:  Comparative  Hazard  Probs  in 
Wbrlti^yidiCd^  „ 

■ 

11.2:  Plan  and  Apply  for  Avionics  Cert. 

4j  1 

5 

11.3:  Estab.  Avionics  Cert.  Proiect 

12.2:  Request  Operational  Approval 
(Ph.2) 

12.3:  Review  Application  Package  (Ph. 

3) 

CSA  provides  partial  basis  fan  certification  until  standards  become  available  and  provides  backgrgmdto  justifa 
and  plan  certification.  An  input  to  certification  plan.  Provides  partial  basis  far  operational  approvatpndfar 
evaluating  applications  for  approval  ■  ■  .  ■  ,  ,  ,  .  ■  ,  ■  ■ 
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Overview  of  Activity  8.8;  Formalize  Scopes  of  Operations 

Description:  As  operational  capability  evolves,  successive  increments  of  capability  will  include  changes  in  the 
operational  scope  of  applications  (including  weather  condition,  distances,  geometries,  airspace,  or  ATC 
surveillance)  and  are  likely  to  require  changes  to  procedures  and  training  and  to  the  functionality, 
performance,  human  interface,  and  certification-level  of  avionics  and  ground  systems.  This  activity 
formalizes  the  agreed  upon  range  of  operational  scopes  supported  near-term  applications  and  the 
demarcations  between  these  and  future  levels  of  operational  capability  that  will  require  separate  (or 
additional)  analysis,  validation,  and  regulatory  approvals  such  as  certification. 

This  activity  is  conducted  in  the  Post  Evaluation  phase. 

Plan  and  Perform:  TBD  POC  =  TBD 

Approve  or  Accept:  TBD  POC  =  TBD 

Products: 

8.8.1:  AC  on  ADS-B/CDTI  Capability  Levels  and  Lims:  This  advisory  circular  (AC)  will  define 
anticipated  boundaries  between  applications  (or  between  levels  of  capability  within  applications)  beyond 
which  additional  safety  analyses  will  be  required,  additional  procedures  and  approvals  will  be  required,  or 
higher  levels  of  certification  will  be  required.  (This  product  is  developed  collectively  for  multiple 
applications.) 


Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

24 

LoE  (sm) 

j 
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Dependencies  and  Phases: 


Post  —I  •-  lA 


De^ 

Con 


Innut  from  Activity: 


1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 
6.1:  Estimate  Performance 


_ Input  via  Product: 


1.2.1:  Detailed  OPS  Concepts 
1.3.1:  Detailed  Systems  Concepts 
6.1.1:  Performance  Expectations 
6.1.2:  Estimated  Performance 
Requirements 


Revised  ops  concepts  support  formalization  of  scopes  of  operation.  Systems  concept  used  to  support  safety, 
analyses.  Performance  estimates  provide  input  to  sdoping  of  operations.  ,  }  .  _ 


J _ M _ 8.1.1:  Coordinated  Safety  Analysis  Plan 

8.1:  Plan  Coord.  Safety  Activities  I  ,  . . L...1—  8.1.2:  Demarcations  in  Safety  Analyses, 

•  Cert.,  and  Approval 

Coordinated  Safety  Activities  Plan  will  guide  safety  malyses.  The  demarcations  between  applications  for  safety^^ 
analysis,  certification,  anddpproval  will  be  validated  arid  published  as  an  AC  by  APS  in  consultation  with  AIP 


8.2:  Summarize  Op.  Services  and  Env't 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 


\ . ..  v:;:. ,  a  , ^ : 


8.2.1:  Operational  Services  and  Env  t 
Definition 

8.3.1:  Operational  Hazard  Assessment 
8.3.2:  Hazard  Analysis  (PHA  or 
SSHA/SHA) 

8.4.1:  ASOR 


Results  of  activities  aid  in  the  development  of  operational  scopes:  t 


Interact  with  Activi 


8.5:  Track  Safety  Issues  During  Dev't - - — 


Issues  arising  from  or  resolved  by  analyses:arecdLt^i(M^Mik^j^ud^a^^k0i^0i^-progra^^i^.^ 


Output  via  Product: 


8.8.1:  AC  hfa  ADS-B/CDTl  Cajialiiliiy  I 
Levels  attd  Litns 


Output  to  Activi 


1.8:  Develop  Requirements  Document 

J _ 1 5.4:  Define  Cockpit  Interface  Stds 

6.2:  Define  Performance  Standards 


AC  provides  inpUt  to  development  of  i^e'quirements  and  standards.  .■  . .  •  ,,  _ 


8.8.1:  AC  ort  ^SrB/pDTI  Capability  'I  . . i'J . |->8.9:  Plan  Safety  for  Implementation 

Levels  and  I  I  I  I„  I  I  1^  .1 J — I _ _ | _ 

ACfXMi^^^Mpt^^‘^W^hif0B§3^entation:sa/etyprogramplans.^ . '  4k  ■' : 

, . . : .  {  I  j  |.  ■»  |  |  |  ||11.2:  Plan  and  Apply  for  Avionics  Cert. 

n'"i-l;,-i  ■  i  11  Is  111  Fcfah  A vinnir«  Prnippt 


11.3:  Estab.  Avionics  Cert.  Project 

8.8.lt  AC  od  ADS-B/CDTl  Capability  12.2:  Request  Operational  Approval 

Levels  and  Lims'Ti  •  (Ph.2) 

s  .  1'.  "',1  12.3:  Review  Application  Package  (Ph. 

AC  provides  useful fnputfof  die  mdmfachp’ejp^^^  application;  Gu^mce  to  ■ 

applicants  and  ACOs/FSDOs  on  scopes  and  limitations  expebted  to  be  associated  with  the  same' or  additional 
reguldtotyid^rovdi^ 
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Overview  of  Activity  8.9:  Plan  Safety  for  Implementation 

Description:  Develop  a  System  Safety  Program  Plan  (SSPP)  to  ensure  that  safety  is  designed  into  the  systems, 
subsystems,  equipment,  facilities,  and  their  interfaces  and  operation.  A  SSPP  provides  a  contractually 
binding  understanding  between  the  FAA  and  a  contractor  on  how  the  contractor  intends  to  meet  specified 
system  safety  requirements.  When  there  are  projects  or  systems  that  have  multiple  subcontractors,  an 
Integrated  System  Safety  Program  plan  (ISSPP)  should  be  developed.  These  plans  should  describe  in  detail 
the  contractor's  safety  organization,  schedule,  procedures,  and  plans  for  fulfilling  the  contractual  system 
safety  obligations.  The  SSPP  is  a  management  vehicle  for  both  the  FAA  and  the  contractor.  The  FAA  uses 
the  SSPP  approval  cycle  to  ensure  that  proper  management  attention,  sufficient  technical  assets,  correct 
analysis  and  hazard  control  methodology,  and  tasks  are  planned  in  a  correct  and  timely  manner.  Once 
approved,  the  FAA  uses  the  SSPP  to  track  contractor  System  Safety  Program  (SSP)  progress.  The  SSPP  is  of 
value  to  the  contractor  as  a  planning  and  management  tool  that  establishes  "before  the  fact"  an  agreement  with 
the  FAA  on  how  the  SSP  will  be  executed  and  in  what  depth. 

Plan  and  Perform:  Product  Team  POC  =  PT  Lead 

Approve  or  Accept:  SEC  POC  =  TBD 

Products: 

8.9.1:  System  Safety  Program  Plan  tSSPPf:  An  approved  System  Safety  Program  Plan  (SSPP)  is  a 
contractually  binding  understanding  between  the  FAA  and  a  contractor  on  how  the  contractor  intends  to  meet 
the  specified  system  safety  requirements.  This  plan  should  describe  in  detail  the  contractor's  safety 
organization,  schedule,  procedures,  and  plans  for  fulfilling  the  contractual  system  safety  obligations. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


F 

Lim 
Dev  — 
Con 


Step 
Imp 
Tra 


Input  from  Activity: 


6.3:  Develop  Ground  System  Specs 


Input  via  Product: 


6.3.1:  Ground  System  Design 
Specification 

6.3.2:  Interface  Documents 


Ground  system  spec  forms  (part  of)  technical  b<^eIini  fdr  mplementation  safety, .actmties. 


8.1:  Plan  Coord.  Safety  Activities 


Coordinated  Safety  Activities  Plan  will  guide  safety  analyses^ 


8.1.1:  Coordinated  Safety  Analysis  Plan 


8.2:  Summarize  Op.  Services  and  Env’t 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  4&  Reqs 


'A  A.. v'  ’Iv.-A’  "‘A  . ' 


Reports  used  as  input  to  implementation  safety  actmties. 


8.5:  T rack  Safety  Issues  During  Dev't 

8.7:  Assess  Comparative  Safety 

8.8:  Formalize  Scopes  of  Operations  ' 


8.2.1:  Operational  Services  and  Env't 
Definition 

8.3.1:  Operational  Hazard  Assessment 
8.3.2:  Hazard  Analysis  (PHA  or 
SSHA/SHA) 

8.4.1:  ASOR 


8.5.1:  Safety  Issues  and  Resolutions 
8.7.1:  Comparative  Safety  Analysis 
8.7.2:  Comparative  Hazard  Probs  in 
Worst  Cred.  Conds 
8.8.1:  AC  on  ADS-B/CDTI  Capability 
Levels  and  Lims 


Safety  issues  ^  to  pi  arming  safety  for  itripiein^dttoi^^A  results  used  as  input  to  implementation 

safety  activities.  AC  provides  input  to  development  of  ihipleriteritdiidh  safety  program  plans.  f  ^  > 


Interact  with  Activit’ 


9.3:  Manufacture  Gnd  Systems  for  Impl 
Implementation  safety  activities  will  impac 


'^^'iMs''dM''^tde:versd, 


Output  via  Product: 


8.9.1:.Sy9kffi  Safety  Progft^iti  ^lati 


liSSt:.''' 


^o^tict  C" ' 


Output  to  Activi 


8.10:  Analyze  Hazards  of  Sub-Systems 
1 8.11:  Analyze  Hazards  Over-All 
8.12:  Analyze  Hazards  of  Ops  & 
Support 

8.13:  Assess  Health  Hazards 
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Overview  of  Activity  8.10:  Analyze  Hazards  of  Sub-Systems 

Description:  Perform  a  Subsystem  Hazard  Analysis  (SSHA).  This  analysis  examines  each  subsystem  or 

component  and  identifies  hazards  associated  with  normal  or  abnormal  operations  and  is  intended  to  determine 
how  operation  or  failure  of  components  or  any  other  anomaly  that  adversely  affects  the  overall  safety  of  the 
system.  This  analysis  should  identify  existing  and  recommended  actions  using  the  system  safety  precedence 
to  determine  how  to  eliminate  or  reduce  the  risk  of  identified  hazards. 

Plan  and  Perform:  Vendor  POC  =  Various 

Approve  or  Accept:  Product  Team  POC  —  PT  Lead 

Products: 

8.10.1:  Subsystem  Hazard  Analysis  tSSHAt:  This  analysis  examines  each  subsystem  or  component  and 
identifies  hazards  associated  with  normal  or  abnormal  operations  and  is  intended  to  determine  how  operation 
or  failure  of  components  or  any  other  anomaly  that  adversely  affects  the  overall  safety  of  the  system.  This 
analysis  should  identify  existing  and  recommended  actions  using  the  system  safety  precedence  to  determine 
how  to  eliminate  or  reduce  the  risk  of  identified  hazards. 


Schedule: 


Con 

Dev 

Urn 

Fuli 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

6 

LoE  (sm) 
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Dependencies  and  Phases: 


Post 
Ful 


De 
Con 


Input  from  Activity: 


6.3:  Develop  Ground  System  Specs 


Input  via  Product: 


J  6.3.1:  Ground  System  Design 
_  Specification 
6.3.2:  Interface  Documents 


Ground  system  spec  forms  (part  of)  technical  haselinefor  mplemmtation  safety  activities.  ^ 


I  18.2.1:  Operational  Services  and  Env’t 


8.2:  Summarize  Op.  Services  and  Env’t 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 


Reports  used  as  input  to  implementation  safety  activities. 


8.3.2:  Kazan 
SSHA/SHA) 
8.4.1:  ASOR 


Deflnition 

8.3.1:  Operational  Hazard  Assessment 
8.3.2:  Hazard  Analysis  (PHA  or 
SSHA/SHA) 


8.7:  Assess  Comparative  Safety 


8.7.1:  Comparative  Safety  Analysis 
8.7.2:  Comparative  Hazard  Probs  in 


r  ;  Worst  Cred.  Conds 


eSA  results  used  as  input  to  implementation  safety  activities. 


8.9:  Plan  Safety  for  Implementation 


8  !  I  1 8.9.1:  System  Safety  Program  Plan 
(SSPP) 


SSPP  provides  framework for  conduct  of  implementation  safety  activities. 


Interact  with  Activit 


9.3:  Manufacture  Gnd  Systems  for  Impl. - ^ - ^  j  li 

_ ^ _ _ _ LJ -  ’  k  'I 

Implementation  safety  activities  will  unpact  manirfactufing  of  ^ound  if steths  andMc^  versa. 


Output  via  Product: 


8, 1 0«1 :  Sii  bsy stem  Hazard  Attalysls 

SSHA  used  as  input  to  the  SHA. 


Output  to  Activit 


8.11:  Analyze  Hazards  Over- All 
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Overview  of  Activity  8.11:  Analyze  Hazards  Over-All 

Description:  Perform  a  System  Hazard  Analysis  (SHA).  The  SHA  determines  how  system  operation  and  hazards 
can  affect  the  safety  of  the  system  and  its  subsystems.  The  SSHA  serves  as  input  to  the  SHA.  The  SHA 
should  begin  as  the  system  design  matures,  at  the  preliminary  design  review  or  the  facilities  concept  design 
review  milestone,  and  should  be  updated  until  the  design  is  complete.  Design  changes  will  be  evaluated  to 
determine  their  effects  on  the  safety  of  the  system  and  its  subsystems.  This  analysis  provides  recommended 
actions,  applying  the  system  safety  precedence,  to  eliminate  or  reduce  the  risk  of  identified  hazards.  The 
techniques  used  to  perform  this  analysis  must  be  carefully  selected  to  minimize  problems  in  integrating  the 
SHA  with  other  hazard  analyses. 

Plan  and  Perform:  Vendor  POC  =  Various 

Approve  or  Accept:  Product  Team  POC  =  PT  Lead 

Products: 

8.1  l.t:  Svstpm  Hazard  Analysis  tSHAt:  The  SHA  determines  how  system  operation  and  hazards  can  affect 
the  safety  of  the  system  and  its  subsystems.  The  SSHA,  when  available,  serves  as  input  to  the  SHA. 


Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

6 

LoE  (sm) 
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Dependencies  and  Phases: 


Post- 
Full-| 
Lim  -j 
Dev  -I 
Con  -n  I 


Step 
r  Imp 
nTra 


Input  from  Activity: 


6.3:  Develop  Ground  System  Specs 


Input  via  Product: 


6.3.1:  Ground  System  Design 
Speciflcation 

6.3.2:  Interface  Documents 


Ground  system  spec  forms  (part  of)  technical  haselihe  for  implementation  sqfetypctmties.  :  V 


18.2.1:  Operational  Services  and  Env’t 


8.2:  Summarize  Op.  Services  and  Env’t 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 


Reports  used  as  input  to  implementation  safety  activities. 


_ 2 

8.7:  Assess  Comparative  Safety  _ . . 

CSA  results  used  as  input  to  implementation  safety  activities. 


Definition 

8.3.1:  Operational  Hazard  Assessment 
8.3,2:  Hazard  Analysis  (PHA  or 
SSHA/SHA) 

8.4.1:  ASOR 


8.7.1:  Comparative  Safety  Analysis 
8.7.2:  Comparative  Hazard  Probs  in 
Worst  Cred.  Conds 


8.9:  Plan  Safety  for  Implementation 
8.10:  Analyze  Hazards  of  Sub-Systems 


8  I  8.9.1:  System  Safety  Program  Plan 

MEL  (sspp) 

8.10.1:  Subsystem  Hazard  Analysis 
(SSHA) 


SSPP  provides  framework  for  conduct  of  implementaiioh  safety  activities.  SSHA  used  as  input  to  the  SHA. 


Interact  with  Activit 


9.3:  Manufacture  Gnd  Systems  for  Impl.l 


Implementation  safety  activities  will  impact  mdnufaciuring  of  ground  systems  and  vice  versa. 


Output  via  Product: 


Output  to  Activi 


40.5:  Coordinate  for  Decisions 
.  J.  J  8.12:  Analyze  Hazards  of  Ops  & 
Support 

8.13:  Assess  Health  Hazards 


Provides  inputs  to  FAA  decision  making  Reports  used  as  input  to  implementation  safety  activities. 
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Overview  of  Activity  8.12:  Analyze  Hazards  of  Ops  &  Support 

Description:  Perform  an  Operating  and  Support  Hazard  Analysis  (O&SHA)  to  identify  and  evaluate  the  hazards 
associated  with  the  environment,  personnel,  procedures,  operation,  support,  and  equipment  involved 
throughout  the  total  life  cycle  of  a  system/element.  The  O&SHA  will  be  performed  on  such  activities  as 
testing,  installation,  modification,  maintenance,  support,  transportation,  ground  servicing,  storage,  operations, 
emergency  escape,  egress,  rescue,  post-accident  responses,  and  training. 

Plan  and  Perform:  Vendor  POC  =  Various 

Approve  or  Accept:  Product  Team  POC  =  PT  Lead 

Products: 

8.12.1 :  Operating  &  Support  Hazard  Analysis  tO&SHA):  The  O&SHA  is  performed  primarily  to  identify 
and  evaluate  the  hazards  associated  with  the  environment,  personnel,  procedures,  operation,  support,  and 
equipment  involved  throughout  the  total  life  cycle  of  a  system/element. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

6 

LoE  (sm) 

— 
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Dependencies  and  Phases: 


Post  ■ 
Full-. 
Lim  -| 

Dev  -j 
Con  —1  I 


Step 
r  Imp 
I—  Tra 


Input  from  Activity: 


6.3:  Develop  Ground  System  Specs 
12.2:  Request  Operational  Approval 
(Ph.2) 

12.6:  Revise  ATC  Orders  &  LOAs 
12.11:  Develop  Maintenance  Procedures 


I  Input  via  Product: 


6.3.1:  Ground  System  Design 
Specification 

6.3.2:  Interface  Documents 

12.2.1:  Formal  Request/Application 

Package 

12.6.1:  Revised  Order  7110.65 
12.6.2:  Revised  Order  7210.3 
12.6.3:  Revised  Order  7610.4 
12.6.4:  Revised  LOAs 
12.11.1:  Maintenance  Procedures 


Ground  system  spec  forms  (part  of)  technical  baseline  far\implementation  safety  activities.  Request  forms 
(portion  of)  basis  of  safety  analysis.  Revised  ATC  documents  support  safety  analyses.  Maintenance  procedures 
required  to  perform  safety  analysis.  ..3''  '  '  '  '  ■’  ,  ■  .  '  ■  " 


4 


8.2:  Summarize  Op.  Services  and  Env't 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 


Reports  used  as  input  to  implementation  safety  activities. 


_ i__ 

8.7:  Assess  Comparative  Safety 


8.2.1:  Operational  Services  and  Env't 
Definition 

8.3.1:  Operational  Hazard  Assessment 
8.3.2:  Hazard  Analysis  (PHA  or 
SSHA/SHA) 

8.4.1:  ASOR 


8.7.1:  Comparative  Safety  Analysis 
8.7.2:  Comparative  Hazard  Probs  in 
Worst  Cred.  Conds 


eSA  results  used  as  input  to  implenientation  safety  activities.  ,  •' 


_ 8.9.1:  System  Safety  Program  Plan 

_  (SSPP) 

o.ii:/vna.yze«azarus^ver-.v..  |  8.11.1:  System  Hazard  Analysis  (SHA) 

SSFF  provides  framework for  conduct  of  implementation  safetyiactiiUies.  Reports  used  as  input  to, ;  ■  f 


8.9:  Plan  Safety  for  Implementation 
8.11:  Analyze  Hazards  Over-All 


Interact  with  Activity: 


- UYJ  — ^ 

Implementation  sqfety  actrvities  will  impact  manifacturing  of  p'ound  systemS  WH  Vtte  'y^Sdlfs 


Output  via  Product: 


r 

. iiMm 

_ _ _ 

Output  to  Activi 


■  -|-  V  >1  f n  '  0.5:  Coordinate  for  Decisions 

..V'.:.  3  r '1  Y:;!3  ■'  III  I  |8|  I  1 8.13:  Assess  Health  Hazards 

8.12.1;  dperating&i^iipport  Hazard  12.5:  Grant  Operational  Approval  (Ph. 

Analysis  (O&SHA)  5) 

,  .  .  .  ^  12.6:  Revise  ATC  Orders  &  LOAs 

■  '  12.14:  Commission  Ground  Systems 

Frovides  inputs  to  FAA  decision  making.  Reports  used  as  input  to  implementation  safety  activities.  O&SIM  used 
as  guidance  in  granting  operational  approyglf  O&SF^'used  of  guiddnc0n:revising  ATC  orders  &  Safety 

analyses  used  as  ^idance  in  commissioning  ^ound  systems.  ■  .  '"thf.".  ’  '  ' 
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Overview  of  Activity  8.13!  ASSCSS  Hcslth  HdZHrds 

Description:  Perform  a  Health  Hazard  Analysis  (HHA)  to  identify  health  hazards,  evaluate  proposed  hazardous 
materials,  and  propose  protective  measures  to  reduce  the  associated  risk  to  an  acceptable  level. 


Plan  and  Perform:  Vendor 
Approve  or  Accept:  Product  Team 


POC  =  Various 
POC  =  PT  Lead 


Products: 

8.13.1:  He?»lth  Hazard  Analy.sis  fHHAf:  An  HHA  identifies  health  hazards,  evaluates  proposed  hazardous 
materials,  and  proposes  protective  measures  to  reduce  the 

associated  risk  to  an  acceptable  level. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


Post- 
Full-. 
Urn  -j 
Dev  -| 

Con  —1  I 


Step 
r  Imp 
,-Tra 


Input  from  Activity: 


6.3:  Develop  Ground  System  Specs 
12.6:  Revise  ATC  Orders  &  LOAs 
12.11:  Develop  Maintenance  Procedures 


(jTOUUd  SyStBffl  spec  foVltlS  (pOTt  If ,  . 

documents  support  safety  analyses.  Maintenance  procedures  required  to  perform  safety  analysis. 


Input  via  Product: 


6.3.1:  Ground  System  Design 
Specification 

6.3.2:  Interface  Documents 
12.6.1:  Revised  Order  7110.65 
12.6.2:  Revised  Order  7210.3 
12.6.3:  Revised  Order  7610.4 
12.6.4:  Revised  LOAs 
12.11.1:  Maintenance  Procedures 

tion  safety  activities.  Revised  ATC  , 


_  8.2.1:  Operational  Services  and  Env’t 

Q  .  _  _  .  /— k  Q\  .  j  -fTi  Ljkk- jli., 1^1.1  Detlnition 

8.2:  Summarize  Op.  Services  and  Env’t  itt  a 

^  ^  o  ^  /  A  .  '  8.3.1:  Operational  Hazard  Assessment 

8.3:  Perform  Safety  Analyses  i  tt  j  a  i  •  /t>tta 

All  ^  C  r  rM.-  !>  O  8.3.2:  Hazard  Analysis  (PHA  or 

8.4:  Allocate  Safety  Objs  &  Reqs  r  s  ^  SSHA/SHA) 

. v:;:;, 8.4.1 :  asor 

Reports  used  as  input  to  implementation  safety  activities. 


1  I  18.7.1:  Comparative  Safety  Analysis 
8.7.2:  Comparative  Hazard  Probs  in 
Worst  Cred.  Conds 


eSA  results  tised  as  input  to .  implementation  "SafetyWttMtw 


8.9:  Plan  Safety  for  Implementation  |  . 

8.11:  Analyze  Hazards  Over-All  u  roiTiw 

8  12-  Analvze  Hazards  of  Ods  &  j.  .,1  8.11.1:  System  Hazard  Analysis  (SHA) 

».1Z.  Analyze  Hazards  01  ups  &  .  ..  8.12.1:  Operating  &  Support  Hazard 

Analysis  (O&SHA) 

SSPP  provides  framework for  conduct  of  implementation  safety  activitiesi  Reports  used  as  input  to 


Reports  used  as  input  to  implementation  safety  aciivities\ 


M  I  MS 

8.7:  Assess  Comparative  Safety 


Interact  with  Activi 


9.3:  Manufacture  Gnd  Systems  for  Impl. 


Implementation  safety  activities  will  impact 


Output  via  Product: 


OutDut  to  Activi 


I _ _ _  f!l -)  0.5:  Coordinate  for  Decisions 

8.13.1:  Health  Hazard  Analysis  0IHA)  .1,  j  .1  .11  L  M.  I  12.6:  Revise  ATC  Orders  &  LOAs 
.  -  ■  V  12.14:  Commission  Ground  Systems 

Provides  inputs  to  FAA  decision  making,  HHA  used  as  guidance  in  revising  ATC  orders  &  LOAs.  Safety  analyses 
used  as  guidance  in  commissioning  ground  systems.  ■  ''  ;  ;  .<  >  _ 
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Overview  of  Activity  9.1 1  Develop  Avionics 

Description:  Develop  avionics  of  suitable  maturity  to  support  the  evaluation  of  this  application  (perhaps  in 

concert  with  other  applications)  during  evaluations  (limited  and  full  evaluations  as  needed).  Develop  avionics 
for  certification  and  operational  use. 

Plan  and  Perform:  Avionics  Manufacturers  POC  =  Various 

Approve  or  Accept:  OCG,  With  AGO  POC  =  OCG  Co-chairs 

Products: 

9.1.1:  Avionics:  Includes  systems  and/or  software  for  limited  evaluation  (in  the  limited  phase),  full 
operational  evaluation  (in  the  OpEval  phase),  for  preparitory  simulations  (in  both  phases)  and  later,  systems 
for  operational  use  (in  the  transition  and  in  service  phases). 

Issues: 

-  In  the  interest  of  achieving  a  wide  spread  ADS-B  capability  in  the  near  future,  some  are  arguing  that 
industry  needs  to  start  installing  avionics  very  soon;  this  could  certainly  be  done  if  one  was  willing  to  accept  that 
currently  available  avionics  may  only  support  the  operational  use  of  a  few  VMC  SF21  applications  and  that  later 
SF  21  applications,  particularly  IMG  applications,  may  require  avionics  replacement;  how  should  we  proceed  to 
capture  the  near  term  benefits  of  ADS-B  while  minimizing  the  need  for  costly  avionics  replacement  programs? 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

24 

24 

48 

LoE  (sm) 

173 


1.3:  Develop  Detailed  Systems  Concepts  _ 2  13  I  I  5  _  1.3.1:  Detailed  Systems  Concepts 

1.4:  Identify  Synergistic  Applications  I  UJ  -1  vSl')  1.4.1:  Synergistic  Application  Sets 
Sets  ::  t  6.1.2:  Estimated  Performance 

6.1 :  Estimate  Performance  Requirements 

Detailed  concepts  help  identify  what  avionics  are  intended  to  do*  Synergistic  Applications  Sets  provide  guidance 


standards  are  ndt  available* 


3.4:  Decision  -  Select  Link(s) 


3.4.1:  Link  Decision 


The  Link  Decision  is  required  so  that  Industry  can  finalize  avionics  desist  without  the  risk  that  the  FAAwill 
later  choose  not  to  support  the  avionics*  data  link  .  ,  <  4/!' '  ^  .  .  ,  < 


5.3:  Design  Cockpit  Interface 


5.3.1:  Cockpit  Interface  Design 


Interface  designs  are  used  to  support  avionics  development 


5.4:  Define  Cockpit  Interface  Stds 
6.2:  Define  Performance  Standards  i  ,  ,  , 


_ 5.4.1:  Cockpit  Interface  Standard 

-^1-  -  6.2.1:  Revised  ADS-B  MASPS 

u.x;  ly  eii  lie  I'enu  nil  a  net;  c>ia  II  u  a  rus  i  r  <  „  .s  .  «  .  i  ;  ^ 

'  V  6.2.2:  Avionics  MOPS 

Standards  provide  baseline  upon  which  final  avionics  designs  are  developed  *use  if  available,  otherwise  use 
prelmmdfy  desi^s:;fff^ 


7.1.1:  Interoperability  Assessment 


7.1:  Analyze  Interoperability 


Provides  guidance  in  the 


7.3:  Validate  Interoperability 


17.3.1:  Interoperability  Validation 
Report 


Provides  guidance  in  avionics  development  for  evaluation  i&for  Implementation. 


Interact  with  Activit 


5.2:  Analyze  Cockpit  Tasks 

5.3:  Design  Cockpit  Interface 

9.2:  Develop  Ground  Systems  for  Eval. 

10.1:  Plan  Joint  Evaluations 

10.2:  Simulate  Mission 


. 


systems  and  vice  versa*  Evaluations  shouh 


11.2:  Plan  and  Apply  for  Avionics  Cert. 
11.3:  Estab.  Avionics  Cert.  Project 
11.4:  Submit  Updated/Supp. 
Information 

12.2:  Request  Operational  Approval 
(Ph.2) 

12.3:  Review  Application  Package  (Ph. 

3) _ 

Cert,  plan  should  be  based  on  avionics  dei 
Office  during  avionics  development.  Apprt 


dfie  consiste. 


3  4 


avionics  design. 
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Output  via  Product: 


9.1.1;  Avionics 


Output  to  Activity; 


6.1:  Estimate  Performance 


9.14:  Avionics 


Avioniesrequiredyfor  me  in  joint  evaluations.  ,<  ' 


rnmam 

™  1 

“1 

1 

□ 

9.1.1:  Avionics 


1- 


11.5:  Test  and  Evaluate  For  Cert. 

11.6:  Issue  ISO  or  STC 

12.4:  Demonstrate  Operation  (Ph.  4) 


Avionics  required  for  certification.  A  vionics  requm^foKoperational  approval. 


9.1.1;  Avionics 


■ 

■ 

3i4 

■ 

H 

mm 

■ 

mmm 

■ 

1 

u 

12.5:  Grant  Operational  Approval  (Ph. 
5) 


Avionics  required for  operational  approval,  yj 


9.14?  Avionics 

Avionics  to  be  used  in  normal  operations. 


|;:a; 

p 

C'. 

J 

[□ 

J 

= 

yj  13.1:  Operate  &  Maintain  Avionics 
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Overview  of  Activity  9.2:  Develop  Ground  Systems  for  Eval. 

Description:  Develop  ground  systems  of  suitable  maturity  to  support  the  evaluation  of  this  application  (perhaps 
in  concert  with  other  applications)  as  needed. 

Plan  and  Perform:  Vendor  POC  =  Various 

Approve  or  Accept:  AND-500  POC  =  AND-500  Lead 

Products: 

9.2.1:  Ground  Systems  for  Evaluation:  Ground  systems  and  interfaces  required  to  support  the  evaluations 
of  the  application. 

Issues: 


-  If  new  ground  systems  or  software  modification  to  existing  ground  systems  are  required,  it  adds  a 
significant  amount  of  time  to  the  schedule  of  what  is  required  to  implement  a  particular  SF21  application 

Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

24 

24 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-, 
Lim  -I 
Dev-. 

Con  -I 


Step 

pimp 

r-Tra 


Innut  from  Activitv:  ■  ■ _ Input  via  Product: _ 


1.3.1:  Detailed  Systems  Concepts 
1.3:  Develop  Detailed  Systems  Concepts  I  I»1  I  I  1  I  I  1 1.4.1:  Synergistic  Application  Sets 

1.4:  Identify  Synergistic  Applications  5.6.1:  Controller  Interface  Design 

Sets  .  .  .  5.6.2:  Mock-Ups  or  Simulation  Gnd 

5.6:  Design  Controller  Interface  Eqpt 

6.1:  Estimate  Performance  Estimated  Performance 

. .  Requirements 

Detailed  concepts  help  identify  wM.  gr(p^nd^^ifir^^f$3i^ndid^io  do.  Synergistic  Applicptm  Sets  provide  ■ 

designs  are  used  to  support  gromd  systems  deyglcgm^nf Estimated perfprmdiwe  requiremerds  medjts, guidance 
in  development  of  ground  system  specs. _ •  ^  -•‘''C-  ■  '  _ 


7.1:  Analyze  Interoperability  1  I  |  J  _ 7.1.1:  Interoperability  Assessment 

7.2:  Define  Ground  System  Interop.  i  ..''f  J'' '* J  ’id- A:  Estimated  Interface  Reqs 

Prify^efgmdanceppthe  development  of  systems  fpj'Jgipt  evaludiions._Estirriated  interface  requirements  used  as 
guidance  in  development  of  ground  systems  for  evaluation.'  '  _ _ ^ ' 


7.3.1:  Interoperability  Validation 
Report 


7.3:  Validate  Interoperability 


Provides  guidance  in  systems  development  for  evaluation. 


Interact  with  Activit 


5.6:  Design  Controller  Interface 
8.6:  Ensure  Safety  of  Testing 
9.1:  Develop  Avionics 
10.1:  Plan  Joint  Evaluations 
10.2:  Simulate  Mission 
12.10:  Inform  Unions 


1,  4,  ,1 . _ ;  ,  ■  ^ 


12.10:  Inform  Unions  ' 

Controller  inteffdee  design  will  impact  deyilpp^ni  ofgrgi^-'^femfmdvice  versallf^^e^^ilflmpqcl 


of  ground  systems  andviceversdSycdjidUi^  becop§^Mdttn 

with  unions  should  be  (in  part)  based  on  gfoid^ systems  desi^. 


Output  via  Product: 


9,2.1:  Ground  Systems  for  Evaluation - - 

Results  of  system  development  used  as  input  to  estimating  performance. 


9.2,1:  Ground  Systems  for  Evaluation - — - - ^10. 


Output  to  Activi 


6.1:  Estimate  Performance 


10.3:  Conduct  Joint  Evaluation 


Ground  systems  required  for  use  in  joint  evaluations: 
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Overview  of  Activity  9.3:  Manufacture  Gnd  Systems  for  Impl. 

Description:  Manufacture  ground  systems  in  accordance  with  the  specifications  and  contract  package 

requirements.  This  activity  includes  system  requirements  review,  system  design  review,  preliminary  design 
review,  critical  design  review,  software  development,  hardware  fabrication,  system  integration  and  testing, 
design  qualification  testing,  and  production  acceptance  testing. 

Plan  and  Perform:  Vendor  POC  =  Various 

Approve  or  Accept:  Product  Team  POC  =  PT  Lead 

Products: 

9.3.1:  Production  System: 

9.3.2;  System  Documentation:  Includes  system  diagrams/schematics,  manuals,  material  lists,  and  other 
documentation  used  to  maintain  and  configure  control  the  system  in  the  field. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

start  Date 

Dur  (wk) 

75 

75 

LoE  (sm) 
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Dependencies  and  Phases: 


Post- 
Full-. 
Urn  -I 


Dev  • 
Con  ^ 


Input  from  Activi 


0.7:  Prepare  Acquisition  Contract 
3.10:  Decision  -  Sel.  Vendor  &  Award 
Contract 

6.3:  Develop  Ground  System  Specs 


Step 
p  Imp 
r"  T  ra 
It  Ifis 

_ Input  via  Product: 


I  I  0.7.1:  Contract  Package 
M7l  0.7.2:  SIR/RFO 

3.10.1:  Contract  Award 
6.3.1:  Ground  System  Design 
"  tE;  Specification 
E'F  6.3.2:  Interface  Documents 


Contract  award  initiates  the  development  of  the  first  production  ground  system.  Ground  systern  specs  provide 


technical  requirements  far  vendc^^^ 

3.11:  Decision  -  Final  Investment 


3.11.1:  Final  Investment  Decision 


The  Final  ]mestment  Decision  allow  program  h  proceed  with  aJulTproduction  run. 


18 

- - L - - _J  3,13.1;  In-Service  Decision 

TTie  ItirService  Decisian! initiates  the  deployment  qf  ^oitnd  systems  to  all  sites.  '  a;? i.s  is  ¥ 


Interact  with  Activi 


8.9:  Plan  Safety  for  Implementation  _  I 

8.10:  Analyze  Hazards  of  Sub-Systems  . I . ■j.i.-J . I'  'I- ‘-4*  ^  I  --I-  - 

8.11:  Analyze  Hazards  Over- All  i  -  f  •  ,  ■ 

8.12:  Analyze  Hazards  of  Ops  &  ,  ';;Ei 

Support  ^  •. 

8.13:  Assess  Health  Hazards  '  '  '  ■ 

12.12:  Develop/Perform  Maint.  Training  ^  V.  j  -i  Je  I  .  ^ 

Implementation  safety  activities  will  impact  manifactmng  of  ground  systems  and  \ 
ground  systems  will  impact  development  of  maintenance  training  and  vice  versa'.  ■ 


Output  to  Activi 


Output  via  Product: 


M.l:  Production  System  I  I  11  '  I  ^  ^ '  H  9.4:  Delfver  and  lutegrale  G.d  Syaems 

9.3,2:  System  Docnmentation:.^-^-;-  ^ 

Production  system  for  delivery  and  installatioq.  ^stem  documentation  to  support  system  installation  and  i :  . , 

Integration. 
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Overview  of  Activity  9.4:  Deliver  and  Integrate  Gnd  Systems 

Description:  This  activity  encompasses  site  preparation,  delivery,  unpacking,  inspection,  installation,  and  testing 
in  a  stand-alone  mode  to  demonstrate  conformance  with  equipment  specifications  and  standards,  followed  by 
integration  and  testing  of  internal  and  external  interfaces  with  other  FAA  systems  and  equipment.  The  system 
contractor  will  perform  stand-alone  testing,  although  it  may  be  independently  contracted  by  the  Regional 
office.  A  Contractor  Acceptance  /  Inspection  (CAI)  team  will  confirm  that  the  system  is  working  properly 
and  ready  for  field  testing.  The  FAA  accepts  the  transfer  of  system  ownership  upon  successful  completion  of 
the  CAI  efforts.  Subsequent  successful  completion  of  operational  (first  system)  and  site  acceptance  (all 
systems)  testing  verifies  proper  integration  and  operation  of  FAA  interfaces.  These  activities  are  performed 
first  for  the  system  delivered  to  the  key  site,  prior  to  the  In-Service  Decision,  and  again  for  the  follow-on 
production  systems  at  the  remaining  sites  after  the  In-Service  Decision. 

Plan  and  Perform:  Vendor,  With  AF,  ACT  POC  =  Various 

Approve  or  Accept:  Product  Team  POC  =  PT  Lead 

Products: 

9.4,1;  Installed  Production  System:  This  represents  the  not-yet-field-tested  system  installed  at  the  site. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

12 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  “1  r  lA 


Input  from  Activity: 


0.7:  Prepare  Acquisition  Contract 
3.10:  Decision  -  Sel.  Vendor  &  Award 
Contract 


Input  via  Product: 


The  cmtrdct  oiitlimi  requirements  jbfddivery  mdmte^atim  of  groimdisystems. 


0.7.1:  Contract  Package 
0.7.2:  SIR/RFO 
3.10.1:  Contract  Award 


9.3:  Manufacture  Gnd  Systems  for  Impl. 


■ 

■ 

8 

1 

□ 

■ 

Hmh 

mms 

m 

■ 

9.3.1:  Production  System 
9.3.2:  System  Documentation 


Production  system  for  delivery  and  installqtio^Jlystm  dqfjimentation  to  support  system  installation  and 
integration.  ■■  ■  r" ; ^ ■: ' -I  - 


12.12:  Develop/Perform  Maint.  Training!- 


12.12.2:  Trained  Maintenance  Personnel 


No  interact  dependencies  defined 


Output  via  Product: 

■ 

m  y  ■ 

IB 

9 

Output  to  Activity: 

9,44  f  Installed  Production  System 

Integrated  system  ready  for  field  tesu 

.. 

33 

1 

12.13:  Field  Test  Ground  Systems 
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Overview  of  Activity  10.1:  Plan  Joint  Evaluations 

Description:  Conduct  an  analysis,  coordinate  with  all  interested  parties,  and  develop  detailed  plans  for 

evaluation  of  the  application,  either  during  a  Limited  Evaluation  or  during  a  full  OpEval.  Define  all  the  issues 
that  need  to  be  resolved;  identify  the  data  needed  to  resolve  these  issues;  define  the  tests,  procedures,  and 
questionnaires  needed  to  capture  the  required  date,  and  assemble  a  team  to  accomplish  this  task.  This 
planning  addresses  both  the  simulation  test  and  evaluation  and  the  flight  test  and  evaluation. 

Plan  and  Perform:  OCG  POC  =  OCG  Co-chairs 

Approve  or  Accept:  OCG  POC  =  OCG  Co-chairs 

Products: 

10.1.1:  Plan  for  Joint  Evaluation:  Two  successive  versions  of  this  plan  will  define  the  details  of  the 
operations  to  be  conducted  and  the  data  to  be  collected  during  the  limited  evaluation  (in  the  limited  phase) 
and  at  OpEval  (in  the  OpEval  phase). 

10.1.2:  Request  for  Spectrum:  Request  for  (interim)  spectrum  required  to  support  the  evaluations  of  the 
application. 

Issues: 

-  For  many  years,  there  has  been  a  clear  distinction  between  the  roles  and  responsibilities  of  pilots  and 
controllers;  many  SF21  applications  propose  to  blur  this  distinction  in  the  interest  of  increased  capacity  and 
efficiency;  would  such  a  change  increase  safety  or  make  things  worse,  8c  how  should  we  test  to  determine  this? 

-  New  procedures  need  to  be  safe  even  under  worst-case  scenarios  (marginal  weather,  pilots  and  controllers 
tired  near  end  of  day,  equipment  failures,  etc.);  how  can  we  test  worst-case  scenarios? 

-  To  what  degree  must  the  controller  be  in  the  loop? 

-  Determine  if  alerting  is  needed 

-  Address  requirements  from  other  activities 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

start  Date 

Dur  (wk) 

20 

20 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-. 
Urn  -| 
Dev-| 

Con 


Step 
r  Imp 
r-Tra 


Innut  from  Activity: 


1.2:  Develop  Detailed  Ops  Concepts 
1.3:  Develop  Detailed  Systems  Concepts 
1.4:  Identify  Synergistic  Applications 
Sets 

2.3:  Analyze  Benefits 
4.2:  Specify  Procedures 
5.3:  Design  Cockpit  Interface 
5.6:  Design  Controller  Interface 
6.1:  Estimate  Performance 


Input  via  Product; _ 


1.2.1:  Detailed  OPS  Concepts 
1.3.1;  Detailed  Systems  Concepts 
1.4.1:  Synergistic  Application  Sets 
2.3.2:  Benefits  Data  Collection 
Requirements 

4.2.1:  Procedures  Specification 
5.3.1 :  Cockpit  Interface  Design 
5.3.2:  Mock-Ups  or  Simulation  Avionics 
5.6.1:  Controller  Interface  Design 
5.6.2:  Mock-Ups  or  Simulation  Gnd 
Eqpt 

6.1.1:  Performance  Expectations 
6.1.2:  Estimated  Performance 
Requirements 

6.1.3:  Performance  Data  Collection 
Requirements 


^rvvidesguidmce  for  condmt  of  activity.  Symr^isticAppUmtiomSmproyidegMi^  , 

conducting  joint  evaluations.  Identifies  benefits  data  to  be  coll0eif  during  evqluationsrSpecifkatipndefi^ 
procedures  to  be  flown  and  data  to  be  collected  during  evaluations.  Human  factors  analyses  are  required  to  plan 
the  mission  simulation.  Data  collection  requirements  for  simulation  and flight  evaluation.  ■  ' '  _ 


1.6:  Develop  Research  Evaluation  Plan  1  [  I  J _ 1.6.1:  Research  Evaluation  Plan 

7.1:  Analyze  Interoperability  '  iMb  1  \n  . A. . L  7.1.1:  Interoperability  Assessment 

7.2:  Define  Ground  System  Interop.  !  v  ^  7.2.1:  Estimated  Interface  Reqs 


The  REP  identifies  data  required  to  address  issues  raised.  Helps  identify  data  tdUectionneeds:jE^^  f 

interface  requirements  provide  inputs  into  joint  evaluation  planning^  V  '  V  f 


3.3:  Decision  -  Go  for  Limited  mil  _ 3.3.1:  Decision  to  Undertake  Limited 

Evaluation  ^  H  L  Evaluation _ 


Decmdn Justifies 


_ _  ,  .  I  I4|  13.5.1:  Decision  to  Plan  for  Full 

3.5:  Decision  -  Go  for  Full  Evaluation  j .  .j ..  fej  ,  |J  >y  |  Evaluation  _ 


Decision  justifies  full  evaluation,  ■  ^  ^  . y _ -- 


.  ^  311  I  17.3.1:  Interoperability  Validation 

7.3:  Validate  Interoperability  Report 


Helps  identify  data  collection  needs,  . .  ^  ^  ^  '  . 


...  ..  ,  .  .  3  4 


10.2:  Simulate  Mission 


314 


10.2.1:  Mission  Simulation  Report 


Simulation  results  applicable  to  flight  eMluation  planning. 
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i/^ii^feiliii^l|gS21ii®iiili^ 

;;;ij;;:t|(:ajs^||i5i£i::!::;:'^'i^i;,-^i;^l::-;;:”3*:;||iS^ 


iiawiis 


'.S : ■  vr'S'««1’i!.5.?;’’1i! 


Interact  with  Activity: 


0.1:  Develop  and  Revise  SF21  MP  p  K  I _ LJ_ _ ■  - . ^ 

0.2 :  Develop  and  Revise  Checklist  -  .;  'S|||iiliiill|S^ 

0.3:  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program  . 

4.2:  Specify  Procedures 

4.5:  Train  for  Procedures  b;.;  Hsfejpt  *  f;\.t:vy  £5l;i||ifip}58fi||gafe 

5.2 :  Analyze  Cockpit  Tasks  '  ■  -■ 

5.5:  Analyze  Controller  Tasks  .  ■;  -  - :  r-^saaittiSeaBSagMSiatiagSga 

7.3:  Validate  Interoperability 

8.2:  Summarize  Op.  Services  and  Env't  - 

8.3:  Perform  Safety  Analyses 

8.4:  Allocate  Safety  Objs  &  Reqs 

8.5:  Track  Safety  Issues  During  Dev't 

8.6:  Ensure  Safety  of  Testing  :*g?|gSiiiiiii^iigiiB^^ 

9.1:  Develop  Avionics 

9.2:  Develop  Ground  Systems  for  Eval. 

10.2:  Simulate  Mission 

11.2:  Plan  and  Apply  for  Avionics  Cert. 

1 1.3:  Estab.  Avionics  Cert.  Project 
12.2:  Request  Operational  Approval 

12.3:  Review  Application  Package  (Ph. 

12.10:  Inform  Unions  ,  -■ ' 

Provides  insight  into  refinement  of  interacting  actMtp products  ma  i>ihe  versa.;  Mc^  identify  cHdriges  needed 

(and  vice  versa).  Evaluations  help  determiPedmsMpt^^^njhdtj^e'ct  ihe^o^ 

of  orocedufes.  Asoecls  of  the  amlicailon  to  oeemlddted  anathe  Methods  of  evaluatioh.should.be  reflected  in  the 


' ;  ''i^  M '. '  :':';1^''  'i  ■  i  i'lvisiiiS  ;  .iSsi  f..v  ".'  f  t;;??  'p,  i-rv ;  -  ;  i;?: 


;?!■!  : :  H  ^ 


:^j||||||i  '  «;  -‘  V  y 


"’C'  ■  7 


is  jii<f i#;!*  ■  ■  7  ■  'r. !'  i  ■] !  ■ ;  ■ ! ^ 


activities  occur  in 
coordinated  With  i 


projects  md  viceyerMrOps  dpp^^^  aem 

approval  wilt  impact  evalddUonplmnmg^^^^  ' 


Output  via  Product: 


10.i.l|lllff'iF6Pi3M 


lit 


Output  to  Activi 


10.2:  Simulate  Mission 

10.3:  Conduct  Joint  Evaluation 

11.2:  Plan  and  Apply  for  Avionics  Cert. 

12.2:  Request  Operational  Approval 

(Ph.2) 


Evaluation  plans  are  inputs  to  certification  plan:  EvMuMmflanrore 


10.1,2:  Request  for  Spectrum  - - - 1 

Plans  affect  spectrum  assigned.  : 


iffputs  to  dpC^  dppfovdl plans: 


11.1:  Obtain  Spectrum 
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10.2:  Simulate  Mission 


Description:  This  is  an  itterative  activity  in  two  phases.  Conduct  a  mission  simulation  prior  to  limited  evaluation 
(in  the  limited  phase)  and  prior  to  full  operational  evaluation  (in  the  OpEval  phase).  Validate  Ops  concepts, 
procedures,  HF  assumptions,  system  interfaces,  and  modify  as  needed. 

Plan  and  Perform:  OCG  POC  =  OCG  Co-chairs 

Approve  or  Accept:  SF21  Steering  Group  POC  =  SF2 1  StG  Co-chairs 

Products: 

10.2.1:  Mission  Simulation  Report:  Two  successive  versions  of  this  report  will  answer  some  questions  on 
the  application,  and  better  enable  conduct  of  the  limited  evaluation  (in  the  limited  phase)  a  more  complete 
evaluation  at  OpEval  (in  the  OpEval  phase). 

Issues: 

-  New  procedures  need  to  be  safe  even  under  worst-case  scenarios  (marginal  weather,  pilots  and  controllers 
tired  near  end  of  day,  equipment  failures,  etc.);  simulators  allow  us  to  test  emergency  situations  and  boundary 
conditions  without  the  risks  associated  with  actual  flight  operations;  but  the  high  fidelity  simulators  that  enable  us 
to  do  such  evaluation  are  very  expensive;  to  control  program  costs,  there  is  a  risk  that  we  may  not  do  enough 
simulation  to  address  the  full  range  of  issues  and  operational  scenarios 

-  To  what  degree  must  the  controller  be  in  the  loop? 

-  Determine  if  alerting  is  needed 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

2 

2 

LoE  (sm) 
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Dependencies  and  Phases: 


6.1:  Estimate  Performance 

2  3 

6.1.1:  Performance  Expectations 

_ 

2"'3 

Provides  inputs  to  development  of  joint  evaluation  parameters.  . >j;;f 

10.1:  Plan  Joint  Evaluations 

■HDI 

■ 

■ 

■ 

■ 

10.1.1:  Plan  for  Joint  Evaluation 

■ 

■  3  4 

■ 

B 

■ 

■ 

B 

B 

Defines  the  details  of  the  operations  and  the  data  to  be'collected.MM^^^  ‘  ^ 

Interact  with  Activity: 


4.2:  Specify  Procedures 
4.3:  Simulate  with  Pilots 
4.4:  Simulate  with  Controllers 
5.2:  Analyze  Cockpit  Tasks 
5.3:  Design  Cockpit  Interface 
5.5:  Analyze  Controller  Tasks 
5.6:  Design  Controller  Interface 
7.3:  Validate  Interoperability 
9.1:  Develop  Avionics 
9.2:  Develop  Ground  Systems  for  Eval. 
10.1:  Plan  Joint  Evaluations 


Evaluations  help  determine  limits  to 


conjunctioiiwith  jpinfevMutiohs.\C0ntrbll^^^^^B^iJ^6MM^^j^ctf^'M1ty^^M^ati6ns. ' 
Interoperabiliity'vaHddtidn'act^itlesoccufM'^hfM^HWtk^ilyMpoltd^^^ya^^ 
planned  use  of  systems.  Results  of  simulatiok  M>iil  lmp(ktt1^dituMdk.pldnning.xd: 


. 

,s';< 


Output  via  Product: 


1 0.2.1 :  Mission  Siiriulation  RepoHi  i 


Output  to  Activity: 


10.1:  Plan  Joint  Evaluations 


Simulation  result  applicable  to  flight  evaluation  planning.-: 
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Overview  of  Activity  10.3i  Conduct  Joint  EvflIuEtion 

Description:  This  is  an  iterative  activity:  collect  and  analysise  data  on  the  application  to  address  some  limited 
aspects  (in  the  limited  phase)  or  all  significant  aspects  (in  the  OpEval  phase). 

Plan  and  Perforin:  OCG  POC  =  OCG  Co-chairs 

Approve  or  Accept:  SF21  Steering  Group  POC  =  SF21  StG  Co-chairs 

Products: 

1fl.3.t :  Joint  Evaluation  Data:  In  the  limited  phase,  this  is  data  from  the  limited  evaluation.  In  the  OpEval 
phase,  this  is  data  from  the  full  operational  evalution.  (Currently,  due  to  the  expected  volume,  these  data  are 
not  expected  to  be  assembled  into  a  single  document.  Data  will  be  retained  by  the  organization  that  collected 
it.) 

10.3.2:  Joint  Evaluation  Report:  Two  successive  version  that  document  the  conclusions  and 
recommendations  from  the  limited  evaluation  (in  the  limited  phase)  and  from  full  operational  evaluation  (in 
the  OpEval  phase). 

Issues: 

-  To  what  degree  must  the  controller  be  in  the  loop? 

-  Determine  if  alerting  is  needed 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

2 

2 

LoE  (sm) 
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Dependencies  and  Phases: 


Post- 
Full-| 
Urn  -j 
Dev-| 

Con  —1  I 


Step 
r  Imp 
r-Tra 


Innut  from  Activity:  H  Input  via  Product: 


6.1:  Estimate  Performance  ^  ^ 


Provides  inputs  to  development  of  joint  evaluation  paramet^s.  ,,  ,  '  , 


8.6:  Ensure  Safety  of  Testing  _ 

9.1:  Develop  Avionics 

9.2:  Develop  Ground  Systems  for  Eval.  9.2.1:  Ground  Systems  for  Evalu; 

10.1:  Plan  Joint  Evaluations  10.1.1:  Plan  for  Joint  Evaluation 

11.1:  Obtain  Spectrum  1 1.1.2:  Assignment  of  Spectrum 

11.6:  Issue  TSO  or  STC  v  -t  'lglSlSIiSI  11-6.1:  TSO  or  STC 

12.5:  Grant  Operational  Approval  (Ph.  12.5.1:  Operational  Approval 

5)  ’  .  •  12.10.1:  Informal  Agreement  to 

12.10:  Inform  Unions  ^  '  Participate  in  Eval. 

Test  safety  strategy  used  as  guidance  in  conduct  of  joint  Valuations.  Avionics  required  for  use  in  joint  . 
evaluations.  Ground  systems  required for  use  in  joint  evaluckidf^lPldns  provide  details  bfjqintjeyaluatic 
Spectrum  assiVnienismtisi  be  in  place  for  ValuatioHsTReVididVauthorizdtidW  Must  be  iWBlMefdr-  V 
evaluations.  Union  agreements  are  required  to. conduct  evaluations.  .  .  -  .  ■ 


6.1.1:  Performance  Expectations 


8.6.1:  Test  Safety  Strategy 
9.1.1:  Avionics 

9.2.1:  Ground  Systems  for  Evaluation 
10.1.1:  Plan  for  Joint  Evaluation 
11.1.2:  Assignment  of  Spectrum 
11.6.1:  TSO  or  STC 
12.5.1:  Operational  Approval 
12.10.1:  Informal  Agreement  to 
Participate  in  Eval. 


'  '  l!?'. 


Interact  with  Activi 


4.2:  Specify  Procedures 
5.2:  Analyze  Cockpit  Tasks 
5.3:  Design  Cockpit  Interface 

5.5:  Analyze  Controller  Tasks  . 

5.6:  Design  Controller  Interface  , 

7.3:  Validate  Interoperability  •• 

Evaluations  help  determine  limits  to  parameters  that  a^ecTthipe^ormance  and  acceptabi 
Cockpit  task  analyses  are  performed  in  conjmctipn  with  joint  Wdliidtibhs.  CphModeftask  iMalys’V 
performed  in  conjunction  with  joint  eydiuatidhsjlnierpperdbiif^fplidatioh  qdiivd^^^^  Wdfi 

evaluations.  .-.s-; . 'I  "'tv,-  fe-'..  ■" 


Output  via  Product: 


. . 


Output  to  Activi 


I  ni '  i '  1-2:  Develop  Detailed  Ops  Concepts 

t  !  p!!  r  tl  ^  S  *1*-*  •  i  ^  13114 1 _ In  1.3:  Develop  Detailed  Systems  Concepts 

10^.2:  Join.  Ev»Iaal(ol.  ft.pbH  .  2.3:  Analyse  BeneflB 

Results  from  evaluation  are  capiured  in  updates  to  concept  documents.  Evaluation  results  enable  validation  of: 
benefits  models  and  dSSUmptidns.j^^^^'ii; a'", I  „  . 


10.3.i!  Joint  EvalUa«b£  bita  Hi’' 


13  4 


6.1:  Estimate  Performance 


Evaluation  results  inUble  ValidM^* 


Provides  inputs  to  FAA  decision  making. 


J  oJ^if dihtSfcyaiuai® 


rmance(models0id  assumptions. 


0.5:  Coordinate  for  Decisions 


Results  of  activities  aid  in  the  development  of  requirements  documents. 


1.8:  Develop  Requirements  Document 
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11.1:  Obtain  Spectrum 


Description:  Manufacturer  makes  application  to  obtain  FAA/FCC  approval  for  the  use  of  frequency(ies)  for 
ADS-B  (Not  necessarily  part  of  the  avionics  certification  process,  but  is  an  input  both  to  avionics  certification 
and  operational  approval).  Includes  descriptions  of  ADS-B  use  in  this  application,  such  as  from  the 
Operations  Concept  and  Systems  Concept,  a  description  of  the  user  community,  geographic  area(s)  of  use  and 
duration  of  use  (one  time/OpEval,  short  term  or  permanent). 

This  activity  is  conducted  in  the  Limited  phase  with  revisions  in  the  OpEval  Phase  and  Post  OpEval  phases. 
Plan  and  Perform:  Avionics  Manufacturers  POC  =  Various 

Approve  or  Accept:  ASR  POC  =  TBD 

Products: 

1  l.t.t :  Request  for  Spectrum/Freq.  Assignment: 

11.1.2:  Assignment  of  Spectrum: 

Issues: 

-  Approval  and  assignment  of  frequency  may  take  longer  than  planned  and  jeopardize  the  associated  phase  of 
this  activity 

-  Will  use  of  the  hardware  for  this  application  force  the  crossing  of  new  thresholds? 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

12 

75 

LoE  (sm) 
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Dependencies  and  Phases: 


Post- 

Full-| 

Lim-| 

Dev  —1 


Step 
r  Imp 
.-Tra 


Input  from  Activity: 


6.1:  Estimate  Performance 


13^4 


Input  via  Product: 


6.1.1:  Performance  Expectations 


Provides  guidance  for  allocating/assigning  specif Uttif or  foiht  evaluations.  ;  .  ^  ‘  f 


10.1.2:  Request  for  Spectrum 


10.1:  Plan  Joint  Evaluations 


Plans  affect  spectrum  assigned. 


Interact  with  Activitv: 


6.2:  Define  Performance  Standards  — 

Definition  of  avionics  performance  standards  and  the 
perform^ jointly,  - 


Output  via  Product: 


Output  to  Activi 


11.1.1:  Request  for  Spectrum/Treq.  - 

Assignmeht::#Sv:gj|^^^gfPt3p|^^ 

6  \  1  Eslab.  Avionics  Cerl.  Project 

Identifies  and  resolves  issues  of  spectrum  for  certficatiomiij  :}  -  :•  -  ' 

1 1.1  .iij’iyisignment Spe|il:|^|g|»:;| 

— — ! - Conduct  Joint  Evaluation 

SpeciruMiSfiii§dMcW^!Mudfhelffpldd^ficffyaliMionSSM^mmmm^  . 

11.1.2:  Assignment  of  Spectritnl 

pra  ISi  11.6:  Issue  TSO  or  STC 

1 3  1 4  1  r  1  6  1 12.1:  State  Intent  to  Conduct  New  Flight 

Ops  (Ph.  1) 

Spectrum  assignment  affects  certification.  Approvals  are  dependent  on  spectrum  assignment.  ;  -  ;  ^  :  ^  ^ 
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Overview  of  Activity  1 1.2:  Plan  and  Apply  for  Avionics  Cert. 

Description:  Manufacturer  develops,  and  submits  to  the  ACO,  a  plan  for  the  certification  of  the  ADS-B,  CDTI 
and  associated  avionics.  Plan  contains  system  description,  basis  of  certification  and  method  of  compliance. 
Functional  Hazard  Assessment,  operational  considerations  (Min.  Equip.  List,  crew  operating  manual,  etc.), 
examples  of  operational  scenarios,  certification  documentation,  project  schedule  and  use  of  designees 
(DER/DAR). 

Plan  and  Perform:  Avionics  Manufacturers  POC  =  Various 

Approve  or  Accept:  Avionics  Manufacturers  POC  =  Various 

Products: 

1 1.2.1 :  Avionic.s  Cert.  Application  &  Plan: 

Issues: 

-  The  plan  may  contain  an  unrealistic  schedule  or  allow  insufficient  time  for  all  certification  steps 

-  Will  this  application  force  the  crossing  of  new  thresholds? 

-  Does  the  schedule  address  all  of  the  activities  and  iterations  required? 

-  Will  this  generation  of  avionics  be  different  and  introduce  new  complexities  for  the  flight  crew? 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

ins 

Start  Date 

Dur  (wk) 

4 

4 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  • 
Full-1 
LIm  -1 
Dev-| 

Con  -1 


Step 
r  Imp 
i-Tra 


Input  from  Activity:  ■  <  H  H  Input  via  Product: 


1.3:  Develop  Detailed  Systems  Concepts 
6.1:  Estimate  Performance 


2  1 3  i  i  5 _ 1.3.1:  Detailed  Systems  Concepts 

I  5  i;  I  i  6.1.2:  Estimated  Performance 
Requirements 

Systems  concepts  are  an  input  to  the  certification  plan:  P  erf  or mancelestimates  provide  (a  portion  of  the  basis 
or  avionics  certification,  f formal  avionics  standards  are  not  avaUabtek  f  ^  b 


^  6  2.4.1:  Industry  Business  Cases 

2.4:  Develop  Industry  Business  Cases - - -71 - r  4  ^  t  -It  c  a  ^ 

c  ^  4-  -o  1  T  ^  1  I  .  I  -  I  J  iPJ .  f  .  J  5.4.1:  Cockpit  Interface  Standard 

5.4:  Define  Cockpit  Interface  Stds  ^  ^  1  o  Anc  a/i  act>c 

6.2:  Denne  Performance  Standards  >  ? 

6.2.2:  Avionics  MOPS 

Industry  business  cases  provide  basis  for  applicants^, certification  plan.  Completion  of  interface  standards  (with 
performance  standards)  facilitates  certification  by  TSO.  Standards  provide  (portion  of)  basis  for  avionics 


3.9:  Decision  -  Industry  Commits  to  _ 

Impl.  '  I'  I-' 


Applicant  commitment  is  required  to  validate  industry  commitment,  S; 


2  ^  m  _ 


3.9.1:  Formal  Notice  from  Applicants 


_  4.2.1:  Procedures  Specification 

e  r.  I.  -e.  T.  .  . . . .  ^-3.1 :  Cocknit  Interface  Design 

c  8.2.1:  Operational  Services  and  Env't 

5.3:  Design  Cockpit  Interface  •  * 

8.2:  Summarize  Op.  Services  and  Env't  -  o  ^  ^  .t-  ■  xr  ^  * 

„  -  _  -  *  .  ,  8.3.1:  Operational  Hazard  Assessment 

8.3:  Perform  Safety  Analyses  a:  J ,  :  032.  Hazard  Analvsis  tPHA  or 

8.4:  Allocate  Safety  Objs  &  Reqs  s&ILVS^^  Analysis  (PHA  or 

,  i  .v;  ■'  8.4.1:  ASOR 

Procedures  flowri  at  OpEyal  provide  partial  basis  for  approval  Preliminary  designs  provide  an  input  to  .  . 
certification  plan  if  standards  are  not  ready.  Safety  analyses  prSvide  a  starting  point  for Jhe  certif cation  process 
(and provides back^ound for  the  cert,  project).  .  ■ ,  .  ‘  ^  : . ^ 


_ MM5 _ I  _  8.7.1:  Comparative  Safety  Analysis 

8.7:  Assess  Comparative  Safety  ■  1  r  I;  ,D  ;  4^,  m  j. -L  8.7.2:  Comparative  Hazard  Probs  in 

. . . .  Worst  Cred.  Conds 

CSA provides  partial  basis  for  certification  until  standafib  become  available  and  provides  background  to  Justify 
and  plan  certification.  An  input  to  certification  plan.  „  . 


5  8.8.1:  AC  on  ADS-B/CDTI  Capability 

8.8:  Formalize  Scopes  of  Operations  — ^ — - 1 — fh — 1 - t  1  j  t  • 

•'  I  '  Levels  and  Lims 


AC  provides  useful  input  for  the  manufacturer  s  use  . 


WSd^sSlMSP-m 


10.1:  Plan  Joint  Evaluations 


Evaluation  plans  are  inputs  to  certification  plan. 


10.1.1:  Plan  for  Joint  Evaluation 


Interact  with  Activif 


9. 1 :  Develop  Avionics  - Ooj - ^  — | — 

Cert  plan  should  be  based  on  avionics  design.  - , 


3  4 

10.1:  Plan  Joint  Evaluations  - nn - 


Evaluation  planning  will  impact  certification  projects  and  vice  versOi 
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Output  via  Product: 

■ 

^  m 

Output  to  Activity: 

ll.24kAvionics  Cert.  Application  & 

Plan 

□ 

n 

11.3:  Estab.  Avionics  Cert.  Project 

11.5:  Test  and  Evaluate  For  Cert. 

~im 

LU 

1 

12.1:  State  Intent  to  Conduct  New  Flight 
Ops  (Ph.  1) 

Receipt  of  the  application  and  plan  kicks  oi 
effort  has  Begun. 

fthe  cert,  project.  Required  for  cert,  testing.  Provides  fvidenqe  c^rt. 
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Overview  of  Activity  11.3:  Estab.  Avionics  Cert.  Project 

Description:  Review  the  manufacturer’s  plan  for  obtaining  certification  of  the  ADS-B,  CDTI  and  associated 
avionics.  Establish  a  certification  project,  points  of  contact  and  team;  provide  ongoing  liaison  and  support 
throughout  the  life  of  the  certification  project. 

Plan  and  Perform:  ACO  POC  =  TBD 

Approve  or  Accept:  ACO  POC  =  TBD 

Products: 

11.3.1:  Certification  Project  Number:  Project  number  established  by  the  aircraft  certification  office  (ACO) 
for  the  certification  project. 

11.3.2:  Cert.  Plan  Initiation  Meeting  &  Report: 

11.3.3:  Request  for  Conformity:  FAA  Form  8120  asks  the  manufacturer  to  submit  FAA  8100-1,  Conformity 
Inspection  Record. 

11.3.4:  Cert.  Issues  Identification  &  Resolution: 

Issues: 

-  Is  the  target  level  of  safety  this  adequate  for  the  intended  use? 

-  Will  this  generation  of  avionics  be  different  and  introduce  new  complexities? 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

4 

4 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


Sqfe^mqly^es  proyj^fq  startin, 
\project). 


Input  from  Activity: 


Ins 


8.2:  Summarize  Op.  Services  and  Env't 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 


1213  41 

n 

n 

r 

_ i 

i 

□ 

Input  via  Product: 


8.2.1:  Operational  Services  and  Env't 
Definition 

8.3.1 :  Operational  Hazard  Assessment 
8.3.2:  Hazard  Analysis  (PHA  or 
SSHA/SHA) 

8.4.1:  ASOR 


II 


the  cert. .. 


_ 

I 

5 

"T" 

1 

t 

1 

^ILI 

8.5:  Track  Safety  Issues  During  Dev't 
8.8:  Formalize  Scopes  of  Operations 


8.5.1:  Safety  Issues  and  Resolutions 
8.8.1:  AC  on  ADS-B/CDTI  Capability 
Levels  and  Lims 


Safety  issues 
ACOs/FSDOs  on  scopes 
approvals. _ 


□ 

L4l5 

□ 

r 

-EL- 

m 

1 

1 

Guidance  tp  appUpants  and 

>e-  same  pr 


8.7:  Assess  Comparative  Safety 


8.7.1:  Comparative  Safety  Analysis 
8.7.2:  Comparative  Hazard  Probs  in 
Worst  Cred.  Conds 


CS4  provides  partial  basis  for  ceri^catm!ap§fi[^d^MiimMm0<^ 
and plm  cert fcgtionr^^^^ '■■■ 


11.1:  Obtain  Spectrum 


3141 


IS 


11.1.1:  Request  for  Spectrum/Freq. 
Assignment  _ 


Identifies  and  resolves  issues  of  spectrum  for  certification. 


11.2:  Plan  and  Apply  for  Avionics  Cert. 


3  4 


3 


11.2.1:  Avionics  Cert.  Application  & 
Plan 


Receipt  of  the  application  and  plan  kicks  off  the  cert,  project. 


Interact  yyith  Activity: 


0.3:  Manage  Issues  and  Risks 
9.1:  Develop  Avionics 


May ^ice  versa).  Cert  plan  should  be  based  on  (avionics  design*  ,  > 

8.5:  Track  Safety  Issues  During  Dev’t  [  1 3  1 4  I  I I  1;  \ ! 'i ; ; J: I 

-i/v  -i*  Tfci _ _ I  ,  I"- 1'  I  I  "I  r . ' .  :  'Xt:;, 

''’9T;'2JS 


10.1:  Plan  Joint  Evaluations 


Issues  gre  coordinated  yvith  program  management  and  other  activities.  Eyaluation  pltmgigg  ^if(fj^pac:t--^}i 
certification  projectsand  vice  versa.  ''  '  ■  • 


Output  via  Product: 

— 

3i 

.  m  ■ 

H  Output  to  Activity: 

11,3.1;  Certification  Project  Number 

1  j,3.2;  Cert,  Plan  Injfiation  Meeting  & 
Report 

)  j,3,3:  Bequest  for  Conformity  .■ 

11,3.4:  Cert.  Issues  Identification  & 
Resolution 

m 

_ 

" 

31.4 . 

„J7 

11.5:  Test  and  Evaluate  For  Cert. 

Required  for  cert,  testing. 
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11.3.2:  Cert.  Plan  Initiation  Meeting  & 
Report  , :  .1::; -  !  £  ’J ‘ ' 

11.3.3:  Request  for  Conformity 

:7:| 

“ 

L 

11.4:  Submit  Updated/Supp. 

7 

Information 

Prompts  manufacturer  for  additional  data. 

'  - . r! "7- . ‘  . :::i7:r'7'  , 

11.3.4:  Cert.  Issues  Identification  &  :  - 
Resoi  u|ipii|||;f|  l';  , 

,7  .r 

,,v' 

11.6:  Issue  TSO  or  STC 

..  „3  lU 

_ 

. 

7 

n 

□ 

Cert  issues  affect  certification. 
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Overview  of  Activity  11.4:  Submit  Updated/Supp.  Information 

Description:  Submit  additional  certification  data,  including  updates  and  revisions,  design  changes,  plan  for 
software  aspects  of  Certification  (PSAC),  System  Safety  Assessment,  environmental  test  results.  Functional 
Hazard  Assessment  and  Certification  Test  Plan.  Provide  data  to  resolve  certification  issues  as  they  arise. 

Plan  and  Perform:  Avionics  Manufacturers  POC  =  Various 

Approve  or  Accept:  ACO  POC  =  TBD 

Products: 

1 1.4.1:  Descriptive  Data: 


11.4.2:  Technical  Information: 
Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

4 

4 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


Input  from  Activity: 


5.3:  Design  Cockpit  Interface 


Post  • 
Full-n 
Urn  -1 
Dev-. 

Con  “1 


Step 

r 

r-Tra 


Input  via  Product: 


5.3.1:  Cockpit  Interface  Design 


Preliminary  designs  provide  an  input  to  certification  plan  if  standards  are  notready. 


5.4:  Define  Cockpit  Interface  Stds 


Data  input  for  certification. 


11.3:  Estab.  Avionics  Cert.  Project 


Prompts  manufacturer  for  additional  data. 


12.3:  Review  Application  Package  (Ph. 

3) 


Input  for  certification. 


5.4.1:  Cockpit  Interface  Standard 


11.3.2:  Cert.  Plan  Initiation  Meeting  & 
Report 

11.3.3:  Request  for  Conformity 


12.3.1:  Operational  Issues  and 
Resolution  Paper 


Interact  with  Activit 


9.1:  Develop  Avionics 

I . I . . . . .  .  '  y  I . 

Additional  information  may  be  requested  by  the  FAA  Certificdtion  Office  duririg  avionics  develdprhent. 


^  V  '  '  4  <  6  JVJS 


Output  via  Product: 


11.4J:  Descriptive  Data  ,  -pgl 

11.4.2:  Technical Inforhtation  I  |3  |4 

Required  for  cert,  testing.  Required  for  cert,  decision. 


OutDut  to  Activi 


11.5:  Test  and  Evaluate  For  Cert. 
11.6:  Issue  TSO  or  STC 


198 


Safe  Flight  21  Generic  Application  Checklist  -  September  28,  2001 

Overview  of  Activity  11.5:  Test  and  Evaluate  For  Cert. 

Description:  FAA  reviews  applicant  data,  proposes  conformity  inspections;  applicant  submits  statement  of 
conformity  and  requests  conformity  inspections  and  FAA  witnessing  of  certification  tests.  If  flight  tests  are 
required,  applicant  submits  Flight  Manual  Supplement  and  flight  test  proposal;  conducts  flight  tests  and 
submits  report  to  AGO. 

Plan  and  Perform:  Avionics  Manufacturers  POC  =  Various 

Approve  or  Accept:  AGO  POG  =  TBD 

Products: 

1 1 .5.1 :  Certification  Test  Report:  Test  report  and  the  substantiating  data. 

Issues: 

-  Simulations  may  be  inadequate  to  resolve  certification  issues 

-  Will  this  application  force  the  crossing  of  new  thresholds? 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

8 

8 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


Input  from  Activity: 


9.1:  Develop  Avionics 

11.2:  Plan  and  Apply  for  Avionics  Cert. 

11.3:  Estab.  Avionics  Cert.  Project 

11.4:  Submit  Updated/Supp. 

Information 


fiiiSiSiiii 


. . 


Avionics  required for  certification.  Required for  cert  testing: 


Input  via  Product: 


9.1.1:  Avionics 
11.2,1:  Avionics  Cert.  Application  & 
Plan 

11.3.1:  Certification  Project  Number 
11.3.2:  Cert.  Plan  Initiation  Meeting  & 
Report 

11.3.3:  Request  for  Conformity 
11.3.4:  Cert.  Issues  Identification  & 
Resolution 

II.4.1:  Descriptive  Data 
11.4.2:  Technical  Information 


No  interact  dependencies  defined 


Output  via  Product: 

■  m  mm 

Output  to  Activity: 

11.5.1:  Certification  Test  Report  ' 

11.6:  Issue  TSO  or  STC 

\3\4\  1  1 

\Report provides  fmalbasis  for  certification  decision.  ■ 
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Overview  of  Activity  11.6;  IssuC  TSO  OF  STC 

Description:  FAA  issues  a  TSO  (Technical  Standard  Order)  or  STC  (Supplemental  Type  Certificate). 

Plan  and  Perform:  ACO  ~ 

Approve  or  Accept:  ACO  POC  -  TBD 

Products: 

11.6.1;  TSO  or  STC: 


Issues: 


-  Will  this  application  force  the  crossing  of  new  thresholds? 
Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

4 

4 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-| 

Dev:i 


step 

r  Imp 
i-Tra 


Input  from  Activity:  ■  H  Input  via  Product: 


„  ,  „  ,  i  .  .  I  I-.  IT  I  I  III  I  9.1.1:  Avionics 

1*1^  r'?  ^  ■  »«1~~  -7 1  I  11.3.4:  Cert.  Issues  Identification  & 

11.3:  Estab.  Avionics  Cert.  Proiect  „  , 

11.4:  Submit  Updaled/Supp.  , 

i*i  11.4.2:  Technical  Information 

11.5:  Test  and  Evaluate  For  Cert.  1 1  i  xt. 

,  -  -  11.5.1:  Certification  Test  Report 

Avionics  required for  certification.  Cert,  issues  affect  certification.  Required for  cert,  decision.  Report  provides 
inal  basis  for  edification  decision.  .  .  ,  ,  • 


'■'.vd'":,; . ' 


11.1:  Obtain  Spectrum 


Spectrum  assignment  affects  certification. 


11.1.2:  Assignment  of  Spectrum 


No  interact  dependencies  defined 


Output  via  Product: _ _ Output  to  Activity: 


1 1.6.1 :  TSO  or  STC '  •  ;  ; - |M|EI| 

niiL 

1  1 

10.3:  Conduct  Joint  Evaluation 

Regulatoif  authorizations  must  be  in  place  for  eyaltiations..:,  . 

. 

V>  ’ 

s  m;  12.2:  Request  Operational  Approval 

7 

-  (Ph.2) 

Required  input  for  operational  approval  :  y  y:,* -..i  ^ 

11.6.i:  TSO  or  STC  .  — | — p- - y|i3.1:  Operate  &  Maintain  Avionics 


TSO  or  STC  required  to  operate  avionics. 
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Overview  of  Activityl2.1  j  State  Intent  to  Conduct  New  Flight  Ops  (Ph.  1) 

Description:  Formal,  written  letter  of  intent  to  implement  and  use  Application  6.1,1  through  issuance  of 

Operations  Specifications  (for  FAR  Parts  121  and  135)  or  Letter  of  Authorization  (for  Part  91).  Meet  with 
FAA  to  discuss  issues  and  prepare  for  formal  request  for  Operational  Approval, 

Plan  and  Perform:  Industry  Stakeholders  POC  =  Various 

Approve  or  Accept:  FSDO  POC  =  TBD 

Products: 

12.1.1:  Request  for  Auth./Statement  of  Intent: 

Issues: 


-  Will  this  application  force  the  crossing  of  new  thresholds? 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

4 

4 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  • 
Full-1 
Urn  -j 
Dev  -1 
Con  — I  I 


Step 

r  Imp 

.-Tra 


Innut  from  Activitv: 


1.2:  Develop  Detailed  Ops  Concepts 


Input  via  Product: 


2  3 


1.2.1:  Detailed  OPS  Concepts 


Provides  guidance  in  planning  ops  approvals  for  joint  evaluations  and  implementation  -  defines  scope  of  ops 


IBI 


2,4:  Develop  Industry  Business  Cases 


Industry  business  cases  provide  basis  for  ops  approval  application: 


3.9:  Decision  -  Industry  Commits  to  1 
Impl. 


Applicant  commitment  is  required  to  validate  industry  commitment 


4.2:  Specify  Procedures  ^  ^ 


Provides  partial  basis  for  statement  of  intent 


11.1:  Obtain  Spectrum 


2.4.1:  Industry  Business  Cases 


3.9.1:  Formal  Notice  from  Applicants 


4.2.1:  Procedures  Specification 


11.1.2:  Assignment  of  Spectrum 


Approvals  are  dependent  on  spectrum  assignments 


1113 

11.2:  Plan  and  Apply  for  Avionics  Cert. 


3  4 


11.2.1:  Avionics  Cert.  Application  & 
Plan 


Provides  evidence  cert  effort  has  begun. 


No  interact  dependencies  defined 


Output  via  Product: 

El  m’:M 

H  Output  to  Activity: 

12.1.1;  Request  for  Auth./Statemen[t  ofii 

1 

a 

^  12.2:  Request  Operational  Approval 
□  (Ph.  2) 

StatemefUlf  inteniisapreregmsite^^  ■■ 
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Overview  of  Activity  12.2:  Request  Operational  Approval  (Ph.  2) 

Description:  Make  formal,  written  request  for  Operation  Approval  with  all  supporting  documentation: 

operations  and  maintenance  manuals,  checklists,  curriculum  changes  and  training/lesson  plans.  Minimum 
Equipment  List  changes,  human  factors  test  results,  certifications  and  certification  basis,  schedule  of  events. 

Plan  and  Perform:  Industry  Stakeholders  POC  =  Various 

Approve  or  Accept:  FSDO  POC  =  TBD 

Products: 

12.2.1:  Formal  Request/Application  Package: 


Issues: 


-  The  schedule  of  events  may  be  unrealistic  and  allow  insufficient  time  to  complete  all  activities 
Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

4 

4 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-. 
Urn  -1 
Dev  -j 
Con  —1  I 


Step 
r  Imp 
I—  Trs 


Input  via  Product: 


Input  from  Activity: 


1.2:  Develop  Detailed  Ops  Concepts 


Provides  guidance  inplanning  ops  approvals  forjointevaluatidns  and  implementation  -  defines  scope  of  ops,  r 


1.2.1:  Detailed  OPS  Concepts 


2  3  4 


4.2:  Specify  Procedures 

5.2:  Analyze  Cockpit  Tasks 

8.2:  Summarize  Op.  Services  and  Env't 

8.3:  Perform  Safety  Analyses 

8.4:  Allocate  Safety  Objs  &  Reqs 


ii'iSfSfflfISlit 


4.2.1:  Procedures  Specification 
5.2.1:  Cockpit  Task  Analysis  Report 
8.2.1:  Operational  Services  and  Env't 
Definition 

8.3.1:  Operational  Hazard  Assessment 
8.3.2:  Hazard  Analysis  (PHA  or 
SSHA/SHA) 

8.4.1:  ASOR 


Procedures  fiown  at  OpEval  provide  partial  basis  fim  appr^ak  Important  ingredient  to  Ops  Approval 
consideration.  Safety  analyses  provide  inputs  to  the  approval  process.  .  '  .  ■  ■  ■ _ 22 


_ _  .  „  .  3 


4.5:  Train  for  Procedures 


3  4 


4.5.1:  Pilot  Training  Materials 


Pilot  training  materials  may  provide  basis  fof'appraved  trainiHg. 


8.7:  Assess  Comparative  Safety 


8.8:  Formalize  Scopes  of  Operations 


8.7.1:  Comparative  Safety  Analysis 
8.7.2:  Comparative  Hazard  Probs  in 
Worst  Cred.  Conds 


ications  for  approval 


8.8.1:  AC  on  ADS-B/CDTI  Capability 
Levels  and  Lims 


Guidance  to  applicants  and  ACOs/FSDOs  on  scopes  and  limitation  expected  to  be  associated  with  the  same  or 
additional  regulatory  approvals.  ''  ‘i '  ‘  "‘'X,  -  -;  ' 


10.1:  Plan  Joint  Evaluations 


10.1.1:  Plan  for  Joint  Evaluation 


Evaluation  plans  are  inputs  to  operational  approval  plans. ,  ...  ,  =  >  ^ 


11.6:  Issue  TSO  or  STC  J  I  3  14  I  I  17 

12.1:  State  Intent  to  Conduct  New  Flight  ^ 

Ops  (Ph.  1)  I . . .  J  Intent  . . 

Required  input  for  operational  approval  Statement  of  intent  is  a  prerequisite  for  formal  request 


11.6.1:  TSO  or  STC 

12.1.1:  Request  for  Auth./Statement  of 

Intent 


Interact  with  Activi 


9.1:  Develop  Avionics 

Approval  plan  should  be  (in  part)  based  on  avionics  des 


3 

10.1:  Plan  Joint  Evaluations 


13^ 


Output  via  Product: 


12.2.1:  Formal  Request/Application  _ 

Package  -  J _ 

Request  forms  (portion  of)  basis  of  safety  analysis. 


Output  to  Activi 


8.12:  Analyze  Hazards  of  Ops  & 
Support 
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12.2.1:  Formal  Request/Application 
Package 

i-  17'^ 

__J  12.3:  Review  Application  Package  (Ph. 

1314!  1  17 

_ 

_ 

□  3) 

Required  for  review. 
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Overview  of  Activity  12.3:  Review  Application  Package  (Ph.  3) 

Description:  Review  applicant’s  package  for  the  specific  application,  evaluate  manuals,  curricula,  training  plans, 
checklists  and  all  other  documentation,  observe  and  evaluate  training,  identify  and  resolve  operational  issues. 
Coordinate  with  FAA  LOBs  concerning  any  elements  of  the  proposed  operations  that  extend  beyond  the 
demarcations  of  systems  and  operations  agreed  to  for  this  level  of  capability  (for  this  application). 


Plan  and  Perform:  FSDO 

POC  =  TBD 

Approve  or  Accept:  FSDO,  With  AFS 

POC  =  TBD 

Products: 

12.3.1:  Operational  Issues  and  Resolution  Paper: 
12.3.2:  Application  Package  Evaluation  Report: 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

8 

8 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  ■ 
Full-. 
Urn  -j 
Dev  -| 

Con  ^  I 


Step 
r  Imp 
i-Tra 


Input  from  Activity: 


8.2:  Summarize  Op.  Services  and  Env't 
8.3:  Perform  Safety  Analyses 
8.4:  Allocate  Safety  Objs  &  Reqs 


2  3  41 


Safety  analyses  provide  inputs  to  the  approval  process. 


8.5:  Track  Safety  Issues  During  Dev't 
8.8:  Formalize  Scopes  of  Operations 


I _ Input  via  Product; _ 


8.2.1:  Operational  Services  and  Env't 
Definition 

8.3.1:  Operational  Hazard  Assessment 
8.3.2:  Hazard  Analysis  (PHA  or 
SSHA/SHA) 

8.4.1:  ASOR 


8.5.1:  Safety  Issues  and  Resolutions 
8.8.1:  AC  on  ADS-B/CDTI  Capability 
Levels  and  Lims 


Sqfety  issues  provide  partial  basis  for  certific^tipmMii^S.  ^resolutions,  dgcurttenf  Guidance  to  appliccmts  and, 
ACOs/FSDOs  on  scopes  and  limitations  expected  ta  he  qssociated  wUh  the  same  or  additional  regulatory 
approvals.  .  " 

05 1  I  I  I  I  8.7.1:  Comparative  Safety  Analysis 
„  ,  8-7.2:  Comparative  Hazard  Probs  in 


Cred.  Conds 


12.2.1:  Formal  Request/Application 
Package 


12.2:  Request  Operational  Approval  I  I 
(Ph.2) 


Required  for  review^-wm;t" '  . . . 


Interact  with  Activi 


0.3:  Manage  Issues  and  Risks  i  . 

9.1:  Develop  Avionics  I  IMl 'j  “W'fv'r; 

May  identify  changes  needed  (and  vice  versa).  Approval pfan  should  be  (in  part)  based  dm^ionicfd0ign$^^:  • 

8.5:  Track  Safety  Issues  During  Dev't  _  |3  UJ _ 

10.1:  Plan  Joint  Evaluations 

Issues  are  coordinated  with  program  management  and  other  activities.  Ops  approvals  are  deyplpped  during,  and 
affected byevaludtidh pldhhing. _ ^ ^ _ '  '  '  '  - 


1  Output  to  Activity: 


12.3.1:  Operational  Issues  and  [  I  [  El  [  j  |  j  [  11.4:  Submit  Uodated/Supp. 

Resolution  Paper;-  I  I  I  I  I  |4| . 1 . | . I  Information 


Output  via  Product: 


42.3.1:  Operational  Issues  and  -  v,;-.  -  pMi  ■  •  1 . 

l^solutioii  Psp®*"  IT  1  ^  ^  12.4:  Demonstrate  Operation  (Ph.  4) 

12,3.2:  Application  Package  Evaluation 

Report;:^;:'  _ 

Issues  and  resolutions  attd  evaluation  of  applicant  materials  are  required  for  demonstration  and  approvaL^orv 


12,3,1;  Operational  Issues  and  EK1"I  '7^ _ 

Resolution  Paper  I  I3|4|  j  |  |7|  |  |  n.S:  Grant  Operational  Approval  (Ph. 

12,3.2:  Application  Package  Evaluation  5) 

Report  ■  ■  P-jft  HI;-  jji ;  j;;-  ;  f!:;;:;- 

Issues  and  resolutions  and  evaluation  of  applicant  materials  are  required  for  demonstration  and  approval?  \ 
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Overview  of  Activity  12.4:  Demonstrate  Operation  (Ph.  4) 

Description:  Conduct  and  evaluate  a  flight  demonstration  of  the  Application. 

Plan  and  Perform:  Industry  Stakeholders  POC  =  Various 

Approve  or  Accept:  FSDO  POC  =  TBD 

Products: 

12.4.1:  Report  of  Operational  Demo; 

Issues: 

-  The  applicant  may  be  unable  to  demonstrate  that  the  new  procedure  can  be  conducted  safely 

-  The  new  procedure  may  require  too  much  heads  down  time 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

4 

4 

4 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  —I  p-  lA 


Input  from  Activity: 

9.1:  Develop  Avionics 

12.3:  Review  Application  Package  (Ph. 

3) 


Input  via  Product; 


9.1.1:  Avionics 
12.3.1:  Operational  Issues  and 
Resolution  Paper 

12.3.2:  Application  Package  Evalnation 
Report 


4viQfiics  required for  operational  approval  j 
required  for  demonstration  and  approval:  -  r~-:  "4 


No  interact  dependencies  defined 


Output  via  Product: 

g| 

wmM 

H  Output  to  Activitv: 

12,4.1;  p.eport  of  Operational  Demo  : 

Demonstration  required  for  Ops  approval 

12.5:  Grant  Operational  Approval  (Ph. 

1  W 

1 

U5) 
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12.5:  Grant  Operational  Approval  (Ph.  5) 


Description:  Assess  results  of  the  application  package  review  and  the  operational  demonstration;  resolve  any 
remaining  issues.  Grant  operational  approval  with  the  issuance  of  Operations  Specifications  or  a  Letter  of 
Authorization. 

Plan  and  Perform:  FSDO,  With  AFS 
Approve  or  Accept:  FSDO,  With  AFS 
Products: 

12.5.1:  Operational  Approval: 


Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

2 

2 

2 

LoE  (sm) 

POC  =  TBD 
POC  =  TBD 
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Dependencies  and  Phases: 


Post  —1  I” 


Input  from  Activity: 


8.12:  Analyze  Hazards  of  Ops  & 
Support 

12.6:  Revise  ATC  Orders  &  LOAs 
12.7:  Revise  the  AIM 
12.8:  Develop/Perform  Controller 
Training 

12.14  Commission  Ground  Systems 


□ 

□ 

r 

□ 

oo 

■ 

a 

m 

n 

asai 

Input  via  Product: 


ISBilS 


8.12.1:  Operating  &  Support  Hazard 
Analysis  (O&SHA) 

12.6.1:  Revised  Order  7110.65 
12.6.2:  Revised  Order  7210.3 
12.6.3:  Revised  Order  7610.4 
12.6.4:  Revised  LOAs 
12.7.1:  Revised  AIM 
12.8.1:  Controller  Training  Materials 
12.14.1:  Commissioned  System 


O&SHA  used  as  guidance  in  ^-anting  operatipnal  approval:  Finql  ATC  documents  support  operational  ~ 
approvals  and  commissioning.  Commissioned  sysjeim  required  before  air-^bmd  operations  can  be  approved. 


9.1:  Develop  Avionics 

12.3:  Review  Application  Package  (Ph. 

3) 

12.4:  Demonstrate  Operation  (Ph.  4) 


3  4 


saiii®* 


9.1.1:  Avionics 

12.3.1:  Operational  Issues  and 
Resolution  Paper 

12.3.2:  Application  Package  Evaluation 
Report 

12.4.1:  Report  of  Operational  Demo 


are 


required  for  demonstration  and  approval.  Demonstration  required  for  Ops  approvalc"  it 


No  interact  dependencies  defined 


Output  via  Product: 

■ 

■  y  M 

I 

H  Output  to  Activity: 

m 

4  0.1:  Develop  and  Revise  SF21  MP 

. 181 . ^ 

|0.2:  Develop  and  Revise  Checklist 

12.5.|.!  Operational  Approval 

0.3:  Manage  Issues  and  Risks 

0.4:  Administer  SF21  Program 

\  Decm0n(s)  will  impact  the  contents  of  the  Wcument(s): 

§^|i;^fflpera;t|p|i§|!|l^prpval||||g^ 

- 

t 

t 

j  ^>Uiiuuv'i  x^tuIUmCttth 

Regulatory  authorizations  niust  he  in  place  far  evaluations,  f 


i:^,5.1;  Operational  Approval  ;  ^ 

Ops’ approval  provides  input  to  revisions  to 

— 

41 

1  Xx*  /  •  Xv6"vis6  me  i^xivi 

:l?.5.1:'ppe]rationai  •  I 

i-v 

/r ; 

'' 

I 

IT 

g  1  xo«x*  vXjpei  dic  lit  iTXdiiUMin  jrm.TionTCiS 

Operational  approval  required  to  operate  avionics.  , .  : 
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Overview  of  Activity  12.6:  Revise  ATC  Orders  &  LOAs 


Description:  Review  and  update  FAA  Order  71 10.65  (Air  Traffic  Control),  FAA  Order  7210.3  (Facility 
Operation  and  Administration),  FAA  )  Order  7610.4  (Special  Military  Operations),  and  selected  letters  of 
agreement  (LOAs)  based  on  an  FAA/Industry  decision  to  implement  this  application. 


Plan  and  Perform:  ATP 

POC  =  TBD 

Approve  or  Accept:  ATS 

POC  =  TBD 

Products: 

12.6.1:  Revised  Order  7110.65:  Order  71 10.65,  Air  Traffic  Control 
12.6.2:  Revised  Order  7210.3:  Order  7210.3,  Facility  Operation  and  Administration 
12.6.3:  Revised  Order  7610.4:  Order  7610.4,  Special  Military  Operations 
12.6.4:  Revised  LOAs:  This  product  addresses  selected  letters  of  agreement  (LOAs). 

Issues: 

-  Union’s  acceptance 

-  Separation  responsibility 

-  Roles  of  controllers 

-  Roles  of  pilots 

-  Equivalent  Level  of  Safety 

Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

12 

16 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  _  _  lA 


Dev 
Con 


Innut  from  Activity: 


_ Input  via  Product: _ 


I  I  I  I  I  1^81  I  13.12.2:  NATCA  Concurrence  on  7110.65 

3.12:  Decision  -  Formal  FAA/Union  _ ;  _ 3.12.3:  NATCA  Concurrence  on  7210.3 

Agreement  3.12.4:  NATCA  Concurrence  on  7610.4 

3.13:  Decision  -  In-Service  3.12.5:  NATCA  Concurrence  on  LOAs 

8.12:  Analyze  Hazards  of  Ops  &  :  3.13.1 :  In-Service  Decision 

Support  :  8.12.1:  Operating  &  Support  Hazard 

8.13:  Assess  Health  Hazards  Analysis  (O&SHA) 

12.13:  Field  Test  Ground  Systems  ;  V  f  ^  f:  8.13.1:  Health  Hazard  Analysis  (HHA) 

f '  L-  T  , 4  12.13.1:  Test  Reports 

NATCA  concurrence  with  proposed  change£re<^u{rei  to  , 

approves  the  commmiQning  Opera, dmj^Msipf^gpndsystems^jP&Sj^^  as  guidm^^J^_  revising  ATC 

orders  &  LOAs.  HHA  used  as  guidance  in  revisit)^  AW  orders  &  LpAsI'FieJA  test  reports  'used'os  input  to  final 
revision  of ATC  documents.  '  ....  .i:.'  '  '  ‘ ' 


4.2:  Specify  Procedures  _ 4  I _ 4.2.1:  Procedures  Specification 

5.5:  Analyze  Controller  Tasks  5.5.1:  Controller  Task  Analysis  Report 

Procedures  flown  at  OpEval  provide  gaHioi:]b^0(FWPTPW^'Amlysi^he!^sde^newfi^f^^AM0Qise^ 
ATC’ Orders  and  LOAs:  \  '■■4,  -  y..  ^ 


71  12.9.1:  Response  to  Draft  7110.65 


12.9:  Coord  w/  FAA  LoBs 


lillMifi 

S'lpiisfS 


12.9.1:  Response  to  Draft  7110.65 
12.9.2:  Response  to  Draft  7210.3 
12.9.3:  Response  to  Draft  7610.2 
12.9.4:  Response  to  Draft  LOAs 


EAA  LOB  commentfon  and  concurrence  with  the  drqft  documents)  are  provided. 


_ _ 7M  I  12.10.2:  NATCA  Response  to  7110.65 

_  M  ~ _ 12.10.3:  NATCA  Response  to  7210.3 

12.10:  Inform  Unions  .  ^  ^ . ;  ! :  12.10.4:  NATCA  Response  to  7610.4 

■>'  '  12.10.5:  NATCA  Response  to  LOAs 

NATCA  Comments  On  Final  drafts  are  provided.  ■  *  ■  r  ■■  z* 


Interact  with  Activi 


12.7:  Revise  the  AIM  _ i  I  I  16 1 71 8 

12.8:  Develop/Perform  Controller  I  -- 

Training 

ATC  Orders,  AIM,  and  Controller  Training  are  revised  in  parallel.  i 


Output  via  Product: 


12.6.1:<Revised  Order  7110.65  I  1  I  I  I  ’171  -  I  I  „  j 

12.6.2;  Revised  Order  7210,3  I  . I . . 1 .  17,1 . 1 .  ‘  , 

12.6.3;  Revised  Order  7610.4  ■'  « . 

12,6.4:  Revised  LOAs 

Revised  A  TC  documents  support  safety  analyses.  •  ..  ;  ■ 


12,6.1:  Revised  Order  7110.65  '  . .  . . ■  L. 

12.6.2:  Revised  Order 7210.3  "  I  M  I  I  I  |8|  | 

12.6.3;  Revised  Order  7610.4 
12.6.4;;  Revised  LOAs - 

Final  ATC  documents  support  operational  approvals  and  commissioning. 


Output  to  Activi 


8.12:  Analyze  Hazards  of  Ops  «& 
Support 

8.13:  Assess  Health  Hazards 


12.5:  Grant  Operational  Approval  (Ph. 

5) 

12.14:  Commission  Ground  Systems 
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12.6.1  r  Revised  Order  7110.65 

12.6.2:  Revised  Order  7210.3 

■■■■■  6 

12.6.3:  Revised  Order  7610.4  ' 
12.6.4|'ReVis^l^H51ffi^ 

12.^:  Coord  w/  Jb  AA  CoKs 

Formal  coordination  of  revisions  with  FAA  LOBs  is  required.  .  - 

12.6.1:  Revised  Order  7110.65 

'  *7' 

12.6.2:  Revised  Order  7210.3 

7 

12.6.3:  Revised  Order  7610.4 

12.10:  Inform  Unions 

12.6.4:  Revised  LOAs 

Formal  coordination  of  revisions  with  unions  is  required. 
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12.7:  Revise  the  AIM 


Description:  Review  and  update  the  Aeronautical  Information  Manual  (AIM)  and  relevant  supplements  as 
required  to  implement  this  application. 

Plan  and  Perform:  AT  POC  =  TBD 

Approve  or  Accept:  AT  POC  =  TBD 

Products: 

12.7.1;  Revised  AIM:  This  revision  includes  the  relevant  supplements. 


Issues: 


•*  Equivalent  Level  of  Safety 

-  Union’s  acceptance 

-  Separation  responsibility 

-  Roles  of  controllers 

-  Roles  of  pilots 

Schedule: 


Con 

Dev 

Urn 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

16 

12 

12 

LoE  (sm) 

217 


Safe  Flight  21  Generic  Application  Checklist  -  September  28, 2001 

Dependencies  and  Phases: 


Input  from  Activity: 


3.12:  Decision  -  Formal  FAA/Union 
Agreement 

3.13:  Decision  -  In-Service 
12.13:  Field  Test  Ground  Systems 


Input  via  Product: 


3.12.6:  NATCA  Concur:  AIM 
3.13.1:  In-Service  Decision 
12.13.1:  Test  Reports 


NATCA  concurrence  with changes  required  to  implement  the  applicatiom  The  Jn-Seryice  Decision 
approves  the  commissioning  and  operational  use  of  ground  systems:  Field  test  reports  used  as  ihput  to  final , 
''reyisiohofATCdo(:um^ts:\.y  . 


12.5:  Grant  Operational  Approval  (Ph. 

5) 


L 

■ 

■ 

□ 

Hi 

■■ 

ti 

if 

Ops  approval  provides  input  to  revisions  to  AIM.  .  ' 


12.5.1:  Operational  Approval 


12.9:  Coord  w/  FAA  LoBs 


FAA  LOB  comments  on  and  concurrence  with  the  drctft  AIM  and  relevant  supplements  are  provided. 


12.9.5:  Response  to  Draft  AIM 


12.10:  Inform  Unions 


M  12.10.6:  NATCA  Response  to  AIM 
Revision 


NATCA  comments  on  the  Final  draft  AIM  and  reliant  supplements  are  provided. 


Interact  with  Activity: 

12.6:  Revise  ATC  Orders  &  LOAs 

12.8:  Develop/Perform  Controller 
Training 

1  H7I8J  I 

\A  TC  OrderSi  AIM,  and  Controller  Training  are  revised  in  parallel 

Output  via  Product: 


12.7.1;  Revised  AIM 


Output  to  Activity: 


12.5:  Grant  Operational  Approval  (Ph. 

5) 

12.14:  Commission  Ground  Systems 


*  ■*  'y  fl.  -rnwrl  T?  A  A  T  ^  1>  ci 

1  |6 

— 1  iz.y:  coord  w/  r  aa  LiOris 

12.7.1:  Revised  AIM 


Formal  coordination  of  revisions  with  FAALOBs  is  required. 


12.7.1:  Revised  AIM 


12.10:  Inform  Unions 


Formal  coordination  of  revisions  with  unions  is  required. 
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Overview  of  Activity  12.8:  Develop/Perform  Controller  Training 

Description:  Develop  and  publish  controller  training  materials.  Perform  controller  training. 

Plan  and  Perform:  AT  POC  =  TBD 

Approve  or  Accept:  AT  POC  =  TBD 

Products: 

12.S.1:  Controller  Training  Materials:  Materials  used  to  train  controllers  on  new/modified  procedures  to  be 
used  to  support  the  application  in  the  NAS. 

12.8.2:  Trained  Controllers:  This  product  in  effect  produces  trained  controllers,  required  to  allow 
implementation  of  the  application  in  the  NAS. 

Issues: 

-  Equivalent  Level  of  Safety 

-  Union’s  acceptance 

-  Geographic  areas  of  implementation 

-  Which  ATC  facilities  are  involved 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

12 

12 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  • 
Full-. 
Lim  “I 
Dev-. 

Con  —1 


Step 
r  Imp 
r-Tra 


Input  from  Activity: 


3.12:  Decision  -  Formal  FAA/Union 
Agreement 

3.13:  Decision  -  In-Service 
12.13:  Field  Test  Ground  Systems 


I  Input  via  Product: 


3.12.7:  NATCA  Concur:  Training 
Materials 

3.13.1:  In-Service  Decision 
12.13.1:  Test  Reports 


NATCA  concurrence  with  proposed  changes  required  to  implement  the  application.  The  In-Service  Decision  _ 
approves  the  commissioning  and  operational  use  of ground  systems.  Field  test  repdr^  used  as  input  to  final 
revision 


4.5:  Train  for  Procedures 


4.5.2:  Controller  Training  Materials 


12.9:  Coord  w/  FAA  LoBs 


May  provide  basis  for  approved  training, 


1 12.9.6:  Response  to  Draft  Controller 
Training  MaPl 


FAA  LOB  comments  on  and  concurrence  with  the  draft  controUeFtraining  material  are  provided  ;  :i?f  ^  ; 


_ 12.10.7:  NATCA  Response  to  Controller 


12.10:  Inform  Unions 


I  Training  Mat’l 


NA  TCA  comments  on  Final  drafts  are  provided,  't  ^  \J: 


Interact  with  Activit 


12.6:  Revise  ATC  Orders  &  LOAs  i  o  i  /  loj  . . . . .  .  . . . 

12.7:  Revise  the  AIM  |,  I . I. 

ATC  Orders,  AIM,  and  GontrpUer  Training  are  revised  in  parallel  = 


Output  via  Product: 


12.8.1:  ControlIef  ,Ti;aihliig  Materials  ■  ^  . [ .  ■  | . . [ . 

Final  ATC  documents  support  operational  approvals  and  commissioning. 


12.8.1;  Contrblier  ti^aiiiliigMateHais  :  12. 

'.,■'1'.;  ■  '  I  I  I  I  I  I  I O  I  _I- . 1 . J 

Formal  c'oof’dinatfd}iMtr‘ainin^  material  with  FAA  LOBs  is  required. . . 


12.8:i^t:Btotl;6nei•3’M^^^^  J  __:r±!i:!!_P:L__  12. 

^  111?  *’  ''  t  1 ' ''  ^^‘'1 — —  1  M  ,  1  ,  „l 

Formal  coSrdii^dtidH  of  training  materials  with  unions  required. 


118.2:  .  :V  ■ — ^ J 12. 


Output  to  Activit 


12.5:  Grant  Operational  Approval  (Ph. 

5) 


12.9:  Coord  w/  FAA  LoBs 


12.10:  Inform  Unions 


A  «  ill,*.-*. min'*  K  W’  i;- ; Li 1  j  Q  j  Q 

'  1 . 1 . 1 . J _ L . 1 . 1 . 1.0.IA. 

Controlkr  tt^tilh'^^eqiitfed  b^oh  system  can  be  commissioned 


laaaysiiaBiitaiigiaiiiig 

\ \ V ...  ' 1  'i  *  ;  ;< ''  " '  —  I  I  I  I 

Requirea  for  new' procedures.  ;.„i  . 


12.14:  Commission  Ground  Systems 


^  13.2:  Operate  &  Maintain  Gnd  Systems 
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12.9:  Coord  w/  FAA  LoBs 


Description:  Formally  coordinate  draft  revisions  to  FAA  ATC  Orders,  the  AIM,  and  selected  letters  of 
agreement  (LOAs)  with  FAA  lines  of  business  (LOBs). 

Plan  and  Perform:  ATP  POC  =  TBD 

Approve  or  Accept:  ATS  POC  =  TBD 

Products: 

12.9.1:  Response  to  Draft  7110.65:  Order  71 10.65,  Air  Traffic  Control 

12.9.2:  Response  to  Draft  7210.3:  Order  7210.3,  Faeility  Operation  and  Admin 

12.9.3:  Response  to  Draft  7610.2:  Order  7610.2,  Special  Military  Operations 

12.9.4:  Response  to  Draft  LOAs:  This  product  is  limited  to  selected  letters  of  agreement  (LOAs). 

12.9.5:  Response  to  Draft  AIM:  This  draft  revision  includes  relevant  supplements. 

12.9.6:  Response  to  Draft  Controller  Training  Mat*l: 

Issues: 

-  Equivalent  Level  of  Safety 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

16 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  • 
Full-1 
Urn  -1 


Dev  • 
Con  -I 


Step 
r  Imp 
r-Tra 


Input  from  Activity 


Input  via  Product: 


12.6:  Revise  ATC  Orders  &  LOAs 

1  6 

1  ;  6  . 

12.6.1:  Revised  Order  7110.65 

12.6.2:  Revised  Order  7210.3 

12.7:  Revise  the  AIM 

12.6.3:  Revised  Order  7610.4 

12.8:  Develop/Perform  Controller 

"p;'' ■ 

12.6.4:  Revised  LOAs 

Training 

12.7.1:  Revised  AIM 

„  ,,  -  12.8.1:  Controller  Training  Materials 

Formal  coordination  of  revisions  with  FAA  LOBs  is  required.  Formal  coordination  of  training  materials  with 

FAA  LOBs  is  required. 

Interact  with  Activit 


0.3:  Manage  Issues  and  Risks  tt- 

May  identify  changes  needed  (and  vice  versa). 


Output  to  Activit' 


12.9.1 :  Response  to, Draft-71 10.65  ..l  i:,  c  _ T  :  I  I 

12.9.2:  Responsfe  to  Draft  7210.3 , '  -l-i-l .  . i . IziXlJ  ^  ^OAs 

12.9.3:  Response  to  Draft  7610.2  ,  ^ ^  ^ 

12.9.4:  Respbtise  fo  Draft  LOAs 

FAA  LOB  continents  oh  and  concuifence  with  the  draft  docurnent(s)  are  provided.  - . 


Output  via  Product: 


12,9.5;  Response  to  Draft  AIM  ,  , - - j — -2. - —  12.7:  Revise  the  AIM 

FAA  LOB  conmehis  on  and  concurrence  with  the  draft  AIM, and. relevarit  s^^  ore  provided. 


12.9.6;  Response  to  Draft  Controller,!  •  I  ■ _ 1  -  I  12.8:  Develop/Perform  Controller 

Training MatM  I  I  I  I  I  mI  I  I  [Training 

FAA  LOB  comments  on  and  concurrence  with  the  draft  controller  training  material  are  provided.  ■;  "  - '  ■ 


12.6:  Revise  ATC  Orders  &  LOAs 
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Overview  of  Activity  12.10j  Inform  Unions 

Description:  Inform  NATCA  of  what  is  proposed  for  controllers  during  Limited  evaluation  and  during  OpEval. 
Notify  NATCA  formally  about  proposed  changes  to  support  the  operational  implementation  of  this 
application.  Negotiate  with  NATCA  to  reach  an  agreement  on  proposed  changes.  [With  application 
involving  ground  system  changes,  it  will  be  necessary  to  deal  with  PASS.] 

Plan  and  Perform:  ATS  POC  =  TBD 

Approve  or  Accept:  FAA  Lines  of  Business,  With  AT  POC  =  Various 

Products: 

12.10.1:  Informal  Agreement  to  Participate  in  EvaL: 

12.10.2:  NATCA  Response  to  71 10.65:  Final  draft  revision  of  Order  71 10.65,  Air  Traffic  Control 

12.10.3:  NATCA  Response  to  7210.3:  Final  draft  revision  of  Order  7210.3,  Facility  Operation  and 
Administration 

12.10.4:  NATCA  Response  to  7610.4:  Final  draft  revision  of  Order  7610.4,  Special  Military  Operations 
12.10.5:  NATCA  Response  to  LOAs:  This  product  addresses  selected  letters  of  agreement  (LOAs). 

12.10.6:  NATCA  Response  to  ATM  Revision:  This  product  includes  relevant  supplements. 

12.10.7:  NATCA  Response  to  Controller  Training  Mat'l: 

Issues: 

-  Equivalent  Level  of  Safety 

-  Union’s  acceptance 

-  Separation  responsibility 

-  Roles  of  controllers 

-  Roles  of  pilots 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

HSEH 

Tra 

Ins 

Start  Date 

Dur  (wk) 

8 

8 

8 

LoE  (sm) 
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Dependencies  and  Phases: 


F 

Urn 
Dev 
Con 


Input  from  Activity: 


4.2:  Specify  Procedures 


Provides  procedures  flown  during  evaluations  for  review. 


12.6:  Revise  ATC  Orders  &  LOAs 
12.7:  Revise  the  AIM 
12.8:  Develop/Perform  Controller 
Training 

12.11:  Develop  Maintenance  Procedures 
12.12:  Develop/Perform  Maint.  Training 


Input  via  Product: 


4.2.1:  Procedures  Specification 


12.6.1:  Revised  Order  7110.65 
12.6.2:  Revised  Order  7210.3 
12.6.3:  Revised  Order  7610,4 
12.6.4:  Revised  LOAs 
12.7.1:  Revised  AIM 
12.8.1:  Controller  Training  Materials 
12.11.1:  Maintenance  Procedures 
12.12.1:  Maintenance  Training 
Materials 


^  Am  A  WAA  AA  AA^^  A.  A  AAA  AAA  AA^ 

Materials 

I f .  .  ^  ^ . 1 . . , . .  . 

Formal  coordination  of  revisions  with  unions  is  reqmredlfFprhialcpprdination  of  training  materials  with  unions 
required.  Maintenance  procedures  required  before  PAAS  will  approvefTrairiing  materials  required  before  PAAS 
willapprove.  .  ^  ^  ‘  * 


Interact  with  Activity: 


9.2:  Develop  Ground  Systems  for  Eval.  3  4 _ L_LJ  i, ;•  v*''*" 

10.1:  Plan  Joint  Evaluations 

Coordination  with  unions  should  be  (in  part)  based  on  ground  systems  design.  Union  approval  will  impact 
evaluation  planning!  _ .  ■  •  ■  -  . _ .  .  ,  .  .  "  ' ' 


Output  via  Product: 


12.10.1:  Info rinal  Agreement  to  ,  ,  .  plEi  h  r  ,  ^  , 

Participate  in  Evfli.  S,- ■  I  I  I  I 

.  . . . 

Union  agreements  are  required  to  cbhduct  evaluations,  -  :  - 


12.10.2:  NATCA  Response  to ,7110.65  ■  III  m  I 

12.10.3;  NATCA  ttespoiise  to  7210.3-  ?'  "■ .  I  M  I  i  I  171  I 

12.10.4:  NAfCA  Response  to  7610.4 

12.10.5:  NATGA  Respoflse  tb  LOAs  i  3.12:  Decision  • 

12.10.6:, NATGA  Reiij[ibiise  tb  AllVt^'i:  Agreement 

ReyisibiSliittililSIi^ 

12.10.7:  NATCA  Respoiise  tb  Corttrbller 
Trbinin|;Ma||§|||^ 

Union  feedback  oh  ihedrdftshouid  lead  toward  corisensuscs..  .. 


:12.10.2:  NATCA  Response  to  7110.65t...--^  1 

12.10.3t^NATCA'^Respbhsfe'  tb-7210i:'l'  't'  I  I  I  1  I  171  I  I  . 

12.i0.5:  NATCA  Response  to  LOAs. 

NATCA  comments  on  Final  drafts  a^e provided.  ,  v™  =1 


12.10.6:  NATCA  Response  to  AIM  7  1  I  _ _ 

- n\ — T”  12.7:  Revis 

Revision  ^  ...1 . Li . I  I  I  I  / 1  I _ 

NATCA  comments  on  the  Final  draft  AIM  and  relevant  supplements  are  provided. 


Output  to  Activit 


10.3:  Conduct  Joint  Evaluation 


Formal  FAA/Union 


12.6:  Revise  ATC  Orders  4&  LOAs 


12.7:  Revise  the  AIM 
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12.10,7;  NATCA  Response  to  Controller  |_ 

wmmm 

P 

□ 

12.8:  Develop/Perform  Controller 
Training 

Training  Mat'l  L 

_ , 

_ 

_ 

_ 

LL 

_ 

_ 

NATCA  comments  on  Final  drafts  are  provided.  .  ...  . 
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Overview  of  Activity  12.11:  Develop  Maintenance  Procedures 

Description:  Develop  the  anticipated  maintenance  procedures  required  to  support  the  ground  systems  in  the 
field. 

Plan  and  Perform:  AF  POC  =  TBD 

Approve  or  Accept:  AF  POC  =  TBD 

Products: 

12.11.1:  Maintenance  Procedures:  Procedures  to  be  used  by  field  maintenance  personnel  to  maintain  the 
systems. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

16 

LoE  (sm) 
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Dependencies  and  Phases: 

Ur 
Dev  - 
Con  ^ 

F 

Fu 

n  - 

’os 

II- 

;t-| 

A 

Step 

r 

J 

np 
-Tra 
l—  Ins 

Innut  from  Activity:  ■ 

M!1 

Input  via  Product: 

6.3:  Develop  Ground  System  Specs 

7[ 

6.3.1 :  Ground  System  Design 
Specification 

6.3.2:  Interface  Documents 

'T  .  i 

Ground  system  spec  provides  technical  baseline  upon  which  maintenance  procedures  are  based,  | 

Interact  with  Activity: 

12.12:  Develop/Perform  Maint.  Training 

L  _ 

1 

M  '  . 

Initial  maintenance  procedures  provide  insight  into  training  requirements  and  vice  versa.  » •  \ 

Output  via  Product: 

II 

■ 

Output  to  Activity: 

12.11,1:  Maintenance  Procedures 

;7- S' 

8.12:  Analyze  Hazards  of  Ops  & 

Support 

“ 

1 

17 

8.13:  Assess  Health  Hazards 

12.12:  Develop/Perform  Maint.  Training 

Maintenance  procedures  required  to  perform  s^ety  analysis.  Maintenance  procedures  required  before  training 
can  bd  developed  or  performed.  ,  '  ,  ,  .  '  . ,  , 

12.11.1:  Maintenance  Procedures  : ; 

7 

12.10:  Inform  Unions 

1^ 

iJ 

Maintenance  procedures  required  before  PAAS  will  approve.  ::  /  >  v 
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Overview  of  Activity  12.12:  Develop/Perform  Maint.  Training 

Description:  Develop  the  appropriate  maintenance  training  materials  to  support  the  training  of  maintenance 
personnel,  and  perform  personnel  training  in  preparation  for  site  installations,  tests,  and  commissionings. 

Plan  and  Perform:  AF  POC  =  TBD 

Approve  or  Accept:  AF  POC  =  TBD 

Products: 

12.12.1 :  Maintenance  Training  Materials:  Materials  used  to  train  system  maintainers  on  the  equipment  to 
be  used  to  support  the  application  in  the  NAS. 

12.12.2:  Trained  Maintenance  Personnel:  This  product  in  effect  represents  trained  maintenance  personnel, 
required  to  allow  the  implementation  of  equipment  required  to  support  the  application  in  the  NAS. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

16 

16 

LoE  (sm) 
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Dependencies  and  Phases: 


Dev 

Con 


Innut  from  Activity: 


6.3:  Develop  Ground  System  Specs 


Input  via  Product: 


6.3.1:  Ground  System  Design 
Specification 

6.3.2:  Interface  Documents 


Grotmd  system  specs  development  of  maintenance  training.  ■ 


12.11:  Develop  Maintenance  Procedures  ^ 


12.11.1:  Maintenance  Procedures 


Maintenancf procedures  required  before  training  can  be  developed  or  performed. 


9.3:  Manufacture  Gnd  Systems  for  Impl.i* 


Interact  with  Activi 


“T:  ^  ^  ^  .Mill  I  i  181  I  ■  .  . . . . . . . 

Manufacturing  of ground  systems  ^vill  impact  development  of  maintenance  training  and  vice  versa,  4:|  ^ 


12.11:  Develop  Maintenance  Procedures  ^ - ^ - - —  : 

InUiaimaintenance  procedures  provide  insight  into  training  requirements  and  vice  versdfi&\ 


OutDut  to  Activi 


Output  via  Product: 


U42.1;  Maintenance  Training  - - W_ - 1  jq:  inform  Unions 

Metenals  r- ■  ■  . LLI . 1 . 1--LLI . 1 . LJ _ 

T)"ainirigmcUeridlsreqiUred  before! 


.  _ ''t«‘  ~ _ ^  9.4:  Deliver  and  Integrate  Gnd  Systems 

12,12.2:  Trained  Maintenance  Personnel _ I _ 1^18  1 12.13:  Field  Test  Ground  Systems 

12.14:  Commission  Ground  Systems 

Trained  maintenance  personnel  required  to  integrate  system  at  site.  Trained  maintenance  personnel  required  to 
ield  test  system.  Trained  maintenance  personnel  required  to  commission  system.  ' _ _ 


12,12,2;  Trained  Maintenance  Personnel — - - 1 - ^ — yj  13,2:  Operate  &  Maintain  Gnd  Systems 

Trained  maintenance  personnel  required  to  maintain  ground  system  throughout  life  cycle.  _ 
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Overview  of  Activity  12.13:  Field  Test  Ground  Systems 

Description:  For  those  systems  designated  for  Independent  Operational  Test  &  Evaluation  (lOT&E), 

independent  operational  test  and  evaluation  is  conducted  at  the  first  site  to  ensure  that  all  critical  operational 
issues  are  resolved  before  the  In-Service  Decision.  lOT&E  is  initiated  upon  receipt  of  an  lOT&E  Readiness 
Declaration  from  ARA-1  certifying  the  system  has  successfully  completed  operational  testing  and  is  ready  for 
lOT&E.  The  system  is  evaluated  for  operational  suitability  and  effectiveness  based  on  the  resolution  of 
Critical  Operational  Issues  (COIs)  in  the  Requirements  Document.  Test  data  from  earlier  test  phases  may  be 
applicable  to  COI  resolution,  as  may  the  results  of  field  familiarization  testing.  Following  lOT&E  at  the  first 
site,  or  following  site  acceptance  test  at  subsequent  sites,  AT  and  AF  personnel  familiarize  themselves  with 
the  new  equipment  in  a  carefully  controlled  operational  environment  to  verify  satisfaction  of  all  operational 
and  support  requirements,  and  to  develop  full  proficiency  in  the  operation  and  maintenance  of  the  new 
equipment.  The  adequacy  and  availability  of  support  materials  such  as  manuals,  handbooks,  and  other 
documentation  is  also  verified.  Successful  completion  of  field  familiarization  testing  results  in  a  declaration 
of  Initial  Operational  Capability  (IOC).  Site  personnel  then  use  the  new  system  operationally  during  the 
Operational  Readiness  Demonstration  (ORD),  usually  in  dual  operation  with  its  predecessor.  During  this 
period,  the  system  is  operated  under  intense  scrutiny  to  discover  and  fix  any  operational  problems,  and  to 
enable  site  personnel  to  become  fully  qualified  to  operate  and  maintain  it.  The  ORD  ends  when  a  Joint 
Acceptance  /  Inspection  (JAI)  team  of  designated  AT  /  AF  personnel  declare  the  system  ready  for  operational 
use. 

Plan  and  Perform:  AF,  With  AT  POC  =  TBD 

Approve  or  Accept:  AF,  With  AT  POC  =  TBD 

Products: 

12.13.1:  Test  Reports:  Reports  of  operational  field  tests  that  are  used  to  validate/invalidate  the  system's 
ability  to  meet  operational  requirements.  These  tests  include  OT&E,  lOT&E  and  field  shakedown  tests. 

12.13.2:  Tested  System:  This  product  represents  the  field-tested  system  ready  for  commissioning. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

12 

12 

LoE  (sm) 
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Dependencies  and  Phases: 


Post  • 
Full-. 
Urn  -j 
Dev  -| 

Con  -I 


■  Step 
r  Imp 
,-Tra 


Innut  from  Activity: 


Input  via  Product: 


9.4:  Deliver  and  Integrate  Gnd  Systems 


Integrated  system  ready  for  field  test. 
12.12:  Develop/Perform  Maint.  Training 


Interact  with  Activi 


Ell 


mmmmmmmfimm 


9.4.1:  Installed  Production  System 


12.12.2:  Trained  Maintenance  Personnel 


0.3:  Manage  Issues  and  Risks 


Output  via  Product: 


12.J3.1:  Test  Reports 


0.5:  Coordinate  for  Decisions 

3.13:  Decision  -  In-Service 

12.6:  Revise  ATC  Orders  &  LOAs 

12.7:  Revise  the  AIM 

12.8:  Develop/Perform  Controller 

Training 


12.8:  Develop/Perform  Controller 

,  Training 

Provides  inputs  to  FAA  decision  making  Reports  tts^d  cfs  input  to  the  In-Service  Decision.  Meld  test  reports  used 

^*0**^**^*  - - '  ^0  —  12.14:  Commission  Ground  Systems 

1243.2: Tested  System  ■  ■  •  ,  '  v  I  I  I  I  I  I  l^i“l . 

i  ri-l  h-'--  -  '  ...S  . .  ■"  I  .IJ  IU'IJ.11,1  II  IM  U.llllllll  I  III  Jim  ■llli;(l|ll<||l|IIL,J^I.I.,,l,.'.l,  I  .  Ill  . 

Test  report  used  as  reference  point  when  commissioning  system.  Tested  system  for  commissioning. 
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Overview  of  Activity  12.14:  Commission  Ground  Systems 

Description:  The  local  AF  technician  certifies  and  commissions  each  site  into  NAS  service  after  dual  operations 
demonstrate  readiness  for  full  operational  service.  An  AT  technician  also  approves  commissioning  when  the 
product  will  be  used  for  air  traffic  control. 

Plan  and  Perform:  AF,  With  AT  POC  =  TBD 

Approve  or  Accept:  AF,  With  AT  POC  =  TBD 

Products: 

12.14.1:  Commissioned  System:  This  product  represents  the  commissioned  system,  approved  for  operational 
use  at  the  site. 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

2 

2 

LoE  (sm) 
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Dependencies  and  Phases: 


Post' 

Full  -|  p  Step 

Urn  -I  p  Imp 

Dev-|  pTra 

_ Input  from  Activity: _ A _ Input  via  Product: _ 

I _ I  I  lAl  I  3.13.1:  In-Service  Decision 

I  r  j  )  I  -j  H  I  8.12.1:  Operating  &  Support  Hazard 
3.13:  Decision  -  In-Service  .  ^  Analysis  (O&SHA) 

8.12:  Analyze  Hazards  of  Ops  &  .  ,  .  .  8.13.1:  Health  Hazard  Analysis  (HHA) 

Support  :  '  :  12.6.1 :  Revised  Order  71 10.65 

8.13:  Assess  Health  Hazards  :  12.6.2:  Revised  Order  7210.3 

12.6:  Revise  ATC  Orders  &LOAS  ,  12.6.3:  Revised  Order  7610.4 

12.7:  Revise  the  AIM  12.6.4:  Revised  LOAs 

12.7.1:  Revised  AIM 

The  In-Service  Decision  approves  the  commissioning  operational  use  of  ground  systems.  Safety  analyses  , 
used  as  guidance  in  commissioning  grotmd  sysilem^f  ^inctl  ^TC,  documents  support  up^i’dtionnl approvals  and , 

12.8:  Develop/Perform  Controller  1,^1  1,1  J  I  -1 12.8.2:  Trained  Controllers 

Training  * . '  '  *** — ' —  12.12.2:  Trained  Maintenance  Personni 

12.12:  Develop/Perform  Maint.  Training  _ _ 

Controller  training  required  before  system  c^'^-^tnmissionedp^^^  maintenctnPf  P^t'sonnel  required  to 

commission  system.  _  ’  '  _ ’  '  "  '  ‘  _ _ 

ill'  1  I  1  0  j  Q  17,  1  1  •  T'psit  "Renorts 

12.13:  Field  Test  Ground  Systems  ~7~p  ,'J  :  | -j  ^91"  12.13.2;  Tested  System 

Test  report  used  as  reference  point  when  commissioning  system.  Tested  system  for  commissioning-  :  :: 


_ Input  from  Activity: 

3.13:  Decision  -  In-Service 
8.12:  Analyze  Hazards  of  Ops  & 
Support 

8.13:  Assess  Health  Hazards 
12.6:  Revise  ATC  Orders  &  LOAs 
12.7 :  Revise  the  AIM 


12.8.2:  Trained  Controllers 

12.12.2:  Trained  Maintenance  Personnel 


No  interact  dependencies  defined 


Output  via  Product: 


Output  to  Activi 


.  .  ,  _  .  .  .  „  ,  1  1  I  I  K1  1 12.5:  Grant  Operational  Approval  (Ph. 

IJ.14.1.5  Commissioned  System  ‘  — [  [  |  |  [  '  [^  [ . 

Commissioned  systems  required  before  air-ground  operations  can  be  approvedi^  x  ; 


12.i4,l5;Commissipned..|^tem:|2^^^ 
Commissioned  system  for  operational  use. 


13.2:  Operate  &  Maintain  Gnd  Systems 
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Overview  of  Activity  13.1:  Operate  &  Maintain  Avionics 

Description:  Avionics  are  maintained  and  operated  to  provide  the  services  defined  by  the  application.  Outages, 
deficiencies,  etc.  are  identified  and  corrected  as  required  to  maintain  the  required  services. 

Plan  and  Perform:  Industry  Stakeholders  POC  =  Various 

Approve  or  Accept:  N/A  POC  N/A 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

999 

LoE  (sm) 
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Dependencies  and  Phases: 


Fi 
Lim 
Dev-i 
Con  -|  1 

Tnnut  from  Activity:  H 

Pos 

Jll- 

it- 

p  1 

A 

fS 

tep 
-  Imp 
p  T  rs 

It  Ins 

II 

1 

iH  t  IH  -  H  Input  via  Product: 

9.1:  Develop  Avionics 

11.6:  Issue  TSO  or  STC 

m 

■ 

Wl 

n 

If 

1  M  9.1.1:  Avionics 

m 

■ 

■■I 

ii 

■1 

4  ^  11.6.1:  TSO  or  STC 

Avionics  to  be  used  in  normal  operations.  fsO  or  STC  required  to  operate  avionics. 

12.5:  Grant  Operational  Approval  (Ph. 
5) 

n 

_i8 

■ 

HI 

■■■I 

ii 

•  11.0 Will 

Operational  approval  required  to  operate  avionics. 

Interact  with  Activity:  H 

■  H  BtH 

-  - - p 

n 

leration  and  maintenance;  ’ 

13.2:  Operate  &  JViaintain  ona  oysiems  p^ 

III 

_ 

-n 

LM 

Operation  and  maintenance  cf  avionics  may  impact  ground  system  op 

No  output  dependencies  defined 
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Overview  of  Activity  13.2:  Operate  &  Maintain  Gnd  Systems 

Description:  Ground  systems  are  maintained  and  operated  to  provide  the  services  defined  by  the  application. 
System  outages,  deficiencies,  etc.  are  identified  in  System  Trouble  Reports  and  corrected  as  required  to 
maintain  the  required  services. 

Plan  and  Perform:  AT,  With  AF  POC  =  TBD 

Approve  or  Accept:  AT,  With  AF  POC  =  TBD 


Schedule: 


Con 

Dev 

Lim 

Full 

Post 

lA 

Step 

Imp 

Tra 

Ins 

Start  Date 

Dur  (wk) 

999 

LoE  (sm) 
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Dependencies  and  Phases: 


Input  from  Activity: 


12.8:  Develop/Perform  Controller 
Training 

12.12:  Develop/Perform  Maint.  Training 


Required  for  new  procedures.  Trained  maintenance  per 


Input  via  Product: 


12.8.2:  Trained  Controllers 

12.12.2:  Trained  Maintenance  Personnel 


- - - ^ 

__ 

CD 

p 

□ 

8_ 

81 

12.14.1:  Commissioned  System 

12.14:  Commission  crouna  ;^ysiems 

1 

j 

[Commi'Ssioned  system  Jbf  operational  use.  ^ 

Interact  with  Activity:  1 

m  -  m  mm 

LJo 

13.1:  Operate  &  Maintain  Avionics 

.1 

_ _ 

_ 

H 

Operation  and  maintenance  cf  avionics  kay  impact  grqund  system  operation  and  rnaintermw^ 


No  output  dependencies  defined 


y 
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APPENDIX  A:  ACRONYMS 


AAL 

FAA  Alaskan  Region 

AGO 

aircraft  certification  office 

ADS-B 

automatic  dependent  surveillance  -  broadcast 

AFS 

FAA  Flight  Standards  Service 

AIM 

Aeronautical  Information  Manual 

AIR 

FAA  Aircraft  Certification  Service 

ALPA 

Air  Line  Pilots  Association  Inti. 

AMS 

acquisition  management  system 

AND 

FAA  Office  of  Commimications,  Navigation,  and  Surveillance 
Services 

AOPA 

Aircraft  owners  and  Pilots  Association 

ASA 

airborne  sepeu’ation  assurance 

ASD 

FAA  Office  of  System  Architecture  and  Investment  Analysis 

ASOR 

allocation  of  safety  objectives  and  requirements 

ASSAP 

airborne  surveillance  and  separation  assurance  processing 

ASY 

FAA  Office  of  System  Safety 

ATA 

Air  Transport  Association 

ATC 

air  traffic  control 

ATM 

air  traffic  management 

ATP 

FAA  Air  Traffic  Planning  and  Procedures  Program 

ATS 

air  traffic  services 

ASY 

FAA  Office  of  System  Safety 

CAA 

Cargo  Airline  Association 

CAASD 

Center  for  Advanced  Aviation  System  Development 

CBA 

cost  benefit  analysis 

CDTI 

cockpit  display  of  traffic  information 

CFIT 

controlled  flight  into  terrain 

CHI 

computer-human  interface 

CNS 

communications,  navigation,  and  surveillance 

CSA 

comparative  safety  assessment 

CONOPS 

concept  of  operations 

CPDLC 

controller/pilot  data  link  communications 

DAR 

designated  airworthiness  representative 

DER 

designated  engineering  representative 

DO-249 

document  249  (RTCA) 

DOD 

Department  of  Defense 

EUROCAE 

European  Organization  for  Civil  Aviation  Equipment 

FAA 

Federal  Aviation  Administration 

FCC 

Federal  Communications  Commission 

FEDEX 

Federal  Express 

FIS 

flight  information  service 

FIS-B 

flight  information  service,  broadcast 
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FSDO 

flight  standards  district  office 

GA 

general  aviation 

GPS 

global  positioning  satellite 

HF 

human  factors 

ICAO 

International  Civil  Aviation  Organization 

ID 

identification 

IFR 

instrument  flight  rules 

IMC 

instrument  meteorological  conditions 

IPT 

integrated  product  team 

JRC 

Joint  Resources  Council 

LAAS 

local  area  augmentation  system 

LOA 

letter  of  agreement 

LOB 

FAA  line  of  business 

MASPS 

minimum  aviation  system  performance  standards 

MHz 

megahertz 

MITLL 

Massachusetts  Institute  of  Technology/Lincoln  Laboratory 

MITRE 

MITRE  Inc. 

MP 

Master  Plan 

MOPS 

minimum  operational  performance  standards 

NAATS 

National  Association  of  Air  Traffic  Specialists 

NAS 

National  Airspace  System 

NASA 

National  Aeronautics  and  Space  Administration 

NATCA 

National  Air  Traffic  Controllers  Association 

OCG 

Operational  Evaluation  Coordination  Group 

OHA 

operational  hazards  analysis 

OpEval 

operational  evaluation 

OpSpecs 

operational  specification 

ORV 

Ohio  River  Valley 

OSA 

operational  safety  analysis 

OSED 

operational  service  and  environment  description 

PASS 

Professional  Airway  Systems  Specialists 

POC 

point  of  contact 

PSAC 

plan  for  software  aspects  of  certification 

ROM 

rough  order  of  magnitude 

RTCA 

RTCA  Inc.  (formerly  Radio  Technical  Commission  for  Aeronautics) 

SARPS 

standards  and  recommended  practices  (ICAO) 

SC 

special  committee  (RTCA) 

SC-186 

special  committee  1 86  (RTCA) 

SF21 

Safe  Flight  21 

SM 

staff  month(s) 

SSG 

Strategic  Support  Group 

STC 

supplemental  type  certificate 

StG 

steering  group 

TBD 

to  be  determined 

TC 

type  certificate 

TEMP 

test  and  evaluation  master  plan 
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TIS-B 

TSO 

UAT 

UPS 

UPSAT 

VDLM4 

VFR 

VMC 

VNTSC 

WAAS 

WG 

WK 


traffic  information  services  -  broadcast 
technical  standard  order 
universal  access  transceiver 
United  Parcel  Service 

United  Parcel  Services  Aviation  Technologies 

very  high  frequency  data  link  mode  4 

visual  flight  rules 

visual  meteorological  conditions 

Volpe  National  Transportation  System  Center 

wide  area  augmentation  system 

working  group 

week(s) 
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